Motivation behind scrum meetings

Scrum meeting is just not "Standing up" ,"meet" and ask 3 questions. There is certain motivation behind this meet. While reading an article I found one of the motivation to be:

When one team member shares an obstacle in the Scrum meeting, the entire team’s resources come together to bear on that problem. Because the team is working together toward a shared goal, every team member must cooperate to reach that goal. The entire team immediately owns any one individual’s problems. [Rising and Janoff, 2000]

This is also in accordance with the lean thinking, Toyota way !!

Agile Pit fall

Even though Agile methods are supposed to reduce the risk of the project, improve the quality of the deliverables, one thing I feel which would complement agile is "measuring the quality in each step". Agile principles and values never talk about any particular "measurement", and the Agile methods who have tons of practices have not given much importance to "measurable result".

Quality

I am sure you would be using the word "quality" hundreds of times a day if you are in software industry. Even though there are various definitions of quality from various school of thoughts, for example:

Quality is conformance to requirements.

and the other one here

Quality is the capacity to remain robust and conformant, while adapting to new requirements.

.

I strongly agree with the second definition. The reason being, I can write my program to conform to requirements but what if, the design is poor ? what if the code is crappy ?

Toyota Way and the Stand up meeting

I remember somebody telling me that, in Toyota manufacturing plant and in the assembly line if somebody discovers some fault in the product, immediately they would raise an alarm. This in turn signals everybody to stop what they have been doing, and approach the person who raised the alarm. All of them in that shop floor in turn would discuss and help the person in resolving the fault he/she has seen.

I believe the same principle is being applied in our daily stand up meeting. Most of the time, the daily stand up meeting is considered as "status meeting". In fact it is not, especially if you look at the third question "Any obstacles stopping the developer from proceeding further?". The reason I believe behind this question is to make the other team members aware of this issue, and in turn all of them can jump together in helping this person out. This is in line with the Toyota manufacturing analogy shown above.

Until we don't understand the principles behind practices, practices remains as practice !!

Discussion with Craig Larman

Nowadays I am working closely with Craig to get a deeper understanding of Agile and Scrum. Here is the summary of key what I understood

1. There is nothing called agile "method". Agile provides principles and values. There are agile methods like XP,Scrum,etc

2. Most of the time people who go through scrum master certification end up becoming "Project managers having Scrum master certification"

3. Scrum Masters are obstacle removers in a project rather than managers controlling the project. I can clearly see in my surroundings, how difficult it is to achieve this particular goal. The reason being most of the people are coming from "Project Management" background !!

Becoming a scrum master is not "practicing some things", it needs total change of mindset, the way we lead life at work, the way we think.

I have started working on implementing "Virtual Lava Lamp", and it looks like a lot of configuration changes needs to be done while integrating Cruise control with lava lamp.

Good quote from Ron Jefferies

The greatest mistake we make is living in constant fear that we will make one.
-- John Maxwell

Why some teams hesitate to maintain charts

I was reading Jim Shores blog, and came across an article where he has recommended to put some thought process if your team hesitates to update the "Big Visible Charts". I am not going to rephrase what he already said, but going to paste his words here:

he first question to ask is, "Did the team really agree to this chart?" An informative workspace is for the team's benefit, so if team members aren't keeping a chart up to date, they may not think it's beneficial. It's possible that the team is passively-aggressively ignoring the chart rather than telling you that they don't want it.

If people won't take responsibility, perhaps you're being too controlling.

I find that when no one updates the charts, it's because I'm being too controlling about them. Dialing back the amount of involvement I have with the charts is often enough to get the team to step up to the plate. Sometimes that means putting up with not-quite perfect charts or sloppy handwriting. I like pretty charts, so that's hard for me to do... but it pays off.

Manual Testing Vs Automated Testing

I have seen posts on the web debating about ONLY in favor of automated testing. My view is we need to have a balance between the automated and manual testing. Couple of points

1. In order to have the tests automated and working with cruise control, a sort of maturity and experience is needed. I have tried implementing TDD with my team, it took really a long time for them to grasp.

2. Even if somebody is trying to automate testing, till date I have not seen anybody implementing them for the entire features. What I have observed is, developers would start writing unit tests and at some point of time, either to meet deadlines or for some reason they would skip writing tests and get into coding straight.

I always think it is a good idea to automate as many tests as possible and also keep manual testing continued.

Manual Testing Vs Automated Testing

I have seen posts on the web debating about ONLY in favor of automated testing. My view is we need to have a balance between the automated and manual testing. Couple of points

1. In order to have the tests automated and working with cruise control, a sort of maturity and experience is needed. I have tried implementing TDD with my team, it took really a long time for them to grasp.

2. Even if somebody is trying to automate testing, till date I have not seen anybody implemeting them for the entire features. What I have observed is, developers would start writing unit tests and at some point of time, either to meet deadlines or for some reason they would skip writing tests and get into coding straight.

I always think it is a good idea to automate as many tests as possible and also keep manual testing continued.

EJDC 2006 Conference

I was planning to post this blog from some time.
on 25th I had been to EJDC conference as a speaker and shared my thoughts on Agile best practices and metrics at EJDC Conference. It was supported by Kushal a non profit organization helping poor children in India.

My presentation was mostly towards the best agile practices that are in town and also some of the most popular agile metrics. I got my presentation reviewed by Craig Larman on thursday and got very good suggestions on usage of some of the "terminologies".

Overall I feel the presentation went very well. First half of the conference was devoted to technology related topics(mostly on SOA).

Humane Interface Vs Minimal Interface

I am very new to Ruby(In fact I am trying to understand what it is), and today I stumbled upon an article by ' Martin Fowler ' which is an eye opener for me and I beleive, this could be a good start for me to start visualizing why there is so much hype about Ruby !! I have suddenly started seeing coding in Java/J2EE as x86 programming !!

Traditional "Done" Vs Agile "Done"

I found this interesting post on the web. Here the author williamcaputo is trying to describe the "thinking" of "done" by the traditional team Vs Agile team.


Traditionally 'done' means "We won't have to work on that anymore - and if we do, somebody must've screwed up." For Agilists 'done' means "We have accounted for what is known. If the situations changes, we expect to revisit this work."

Thus the two approaches have different goals: One is to finish, the other is to keep pace with change.

How Idiotic is to track % completion of the project

In recent days, I have been working closely with Craig larman to bring out a new domain modal based on scrum for Valtech cockpit. During the discussion with Craig, he talked about how stakeholders ask for % completion of the project and, how our PMs give them a %(percentage) !! It all looks idiotic if you read the rest of the following section.

The core reason for introducing agile methods in software is to manage the changes, adapt accordingly and be open to get changes. As per the statistics, change requests increases as the project size increases. If we are getting more changes obviously it would add more effort to existing estimated effort and this becomes a moving target. How can anybody estimate how much % of project has completed in this scenario? It is as good as telling not the truth, if I tell my stakeholder that we have finished 50% project !! (Unless you add a clause saying "as of today")

So, instead of using "% Complete" as the measurement, one can use the "estimated effort" remaining to complete the project

What we miss when we talk about TDD

Here is a classic definition of TDD from Agile discussion group,

Classic TDD (and just TDD for that matter) is: write a little example of a (sub)set of behavior, write a little code so that the example works, refactor, repeat.

What we miss all the time while defining TDD is the "Refactor" part !!!

Valtech's global development can lead to world class software development

I was having a chat with Thierry Cavrel while sipping coffee, and we were discussing a host of subjects. In fact, I wanted to share my perspective of how collaborative development can be achieved in delivering quality software at Valtech. Each of the Valtech's units distributed across the world has unique features. Valtech Germany is famous for their technology presence, France for there Project management/delivery capability, India for having expertise in Agile, US for there training and consulting expertise, so on and so forth. Each of these centers have key resources who are making difference. Considering that these resources are used collaboratively, Valtech can deliver any critical project and deliver it successfully.

So, Valtech is a classic example of Global Software development Village !!!

anti-determinism-law

Here is another interesting quote read online (Author: William Bogaerts)

A timeline is going to be difficult, even if you know _all_ the details
beforehand. You know, there is an "anti-determinism-law" in physics
that
says you cannot know both the position and speed of a particle exactly.
There's a similar law in software engineering that says you cannot know
the effort and the requirements together exactly.

Making decisions late in the game

I found the following interesting discussion in the agile discussion forum, and was written by a software developer John: The discussion was about XPs practice "Make the decision as late as possible"

Reminds me of an older paper I recently read (but whose title eludes
me).

According to the premise of the paper, the boundaries that define
components should be drawn based on the difficulty of design choices.

An example might help to illustrate this. Suppose Joe and Harry are
contracted to write a spell-checker.

The customer wants multilingual support, so Joe and Harry agree to use
unicode. This decision is trivial (customer requirement), so there is
no need to abstract the concept of text within the application---they
can use unicode characters and strings.

Now let's say Joe suggests using a map (hashtable) to perform spell-
checking. This seems like an obvious choice to Joe because it makes it
easy to see if a word is spelled correctly. Harry, however, points out
that a map doesn't provide any means of suggesting a corrected
spelling, and recommends a sorted list instead, because it's easier to
find a closest match.

The fact that Joe and Harry didn't come up with the same solution to
the problem indicates the design of the spell-checking algorithm is
more difficult than the question of how to represent text.
Consequently, it's probably a good idea to encapsulate the
spell-checking algorithm, isolating its implementation details from
the rest of the application. This way, if they head down the wrong
path, they can correct their mistake with minimal impact to the rest
of the application.

I agree with this general philosophy. If a design choice isn't obvious
to you, that's because you don't have enough information. If you don't
have enough information, and make a decision anyway, you're more
likely to get it wrong. So in those areas where you can't immediately
(or unanimously) decide, it's best to introduce enough abstraction so
that if you choose poorly, you can correct your mistake without having
to rewrite the whole application.

Elephant looking from various directions

I found this interesting piece of information on the agile forum by a member (Philip, no last name). This is what I always preach when somebody asks me the relation. Also, it is in synch with my thought that Agile is spirituality rather than a religion !!

All the agile processes use automated tests and frequent releases.

All the books about Agile development represent consultants telling
specific teams what to do, and making up jargon. They are all blind
men groping the same elephant, but each has named their part of it
something different. It's all the same elephant.

Crossing the chasm

I found this nice article on Dr.Dobb's portal, which talks about companies based on their ability to take risk and move towards agility.

http://www.ddj.com/dept/architect/187200223;jsessionid=4MASEABOIHHWYQSNDBCCKH0CJUMEKJVN

Pros and Cons of using Index cards over computer

Agile proposes people to make use of Index cards during requirement analysis and estimation phases. As per agile, it would help the development team and other stakeholders to change things quickly, ask questions without really "handing off" documents and waiting for things to happen.

Here are some of my thoughts on pros and cons of using 3*5 Index cards:

Pros:
1. Very agile. You can modify the information with ease.
2. Sticking them to the wall keeps the information in front of your eyes all the time.
3. Easy to carry from one place to other.

Cons:
1. Chances of getting lost are high
2. You may need a good secure storage space. Because over a period of time, the paper might become old and the chances of paper getting torn, and information getting lost is high.

One of the key advantage of using Spreadsheet(in parallel with Index cards) are
1. Quality of information would stay intact over a long period of time.
2. Sharing the information with onsite team located in a distributed team is easy
3. Spreadsheet is idea to keep track of information which keeps changing quite frequently.