Monday, March 16, 2009

Testing in Scrum

This is never a new topic. Probably it is one of most discussed topics in Scrum community. But according to our practices we have to highlight it again.

In Scrum training, when the team members were asked what would be definition of done in a sprint most of the members would say all test tasks tasks if they have enough resources and time. But in contrast, in the practices, people would talk a lot of impediments of doing performance test, regression test, exploratory test bala bala. If the team were asked further what the impediments preventing they get these test activities done would be. They may talk about tight schedule, no automation test tools, less competences ... if you ask the team did you guys speak it out in the sprint planning meeting, you probably could hear a short silence.

Something are missing in such Scrum teams.

A classical test team (in waterfall world) were asked to test something they never have a thumb on software design and coding rather focus and limited in "testing" with a delivery from developers. In Scrum, there is no boundary between design/code and test so the test engineers are often get confused and lost. As a member of Scrum team, a test engineer suppose to be having more competences in test activities than others and she/he supposed could evaluate the item of a product backlog with his/her professionalism and experiences (in test). For instance, in the first sprint if the team could not complete the regression test or performance within the sprint if the PO or team thought it was necessary somebody (especially test engineer) should point it out during the review and increase the estimated size of similar items in the product backlog reasonably.

The situation would get worse when there were a "system test team", so called, along with Scrum teams. In most case I met, the Scrum teams there will have a couple of "agile testers" who would do sort of verification of new features committed by the team. The system level testing, performance, exploratory test will be done in "system test team". But unfortunately, most of "system test team" do not follow Scrum and have no influences in the Scrum teams' planning. On one hand, "system test team" do not give their commitments (since they were asked to test the releases from the Scrum team with no idea how many efforts need to complete all test of the commitments made by the Scrum team), on the other hand, the Scrum teams do not count the efforts of the "system teat team" when they make commitments. The predictable results would be have a long "stabilization" sprint and bug explosion within that sprint. Finally the teams have to release buggy software.

I'll discuss about how to avoid this later...

Sunday, February 15, 2009

How many impediments you removed

I noticed some Scrum teams don't raise any impediments at all during the whole Sprint. There were two possible situations:
  1. There is no impediments at all in the Sprint;
  2. Nobody cares about impediments.
I believe that option no.1 is never the case in any Sprint.
Removing impediments is the first priority job for Scrum Master who suppose to serve and protect the team. No other activities are more important for him than tackling the impediments down. If we have to do performance assessment against a Scrum Master the amount of impediments removed by Scrum Master should be counted in.

Removing impediments is never trivial. Scrum Master has to do it with his/her best and get it done ASAP. I've heard from one Scrum Master of a ScrumButt team that I've not enough time to do it since I have to take some development tasks... eh... I was told Scrum Master have to take some development tasks. Whoever told the Scrum Master like that or do not treat removing impediments as the first priority activities for Scrum Master does not know Scrum at all. (in the Sprint review meeting the team seemed got a few open issues, some are even been forgotten totally till the end of the Sprint, let alone the commitments met).

Since the team does not know when/what/how many impediments they may face in a Sprint so Scrum Master should be ready at anytime to remove it as much as he/she can during a sprint. Thus we should have full time Scrum Master and Scrum Master is really a challenge role in Scrum.

How many impediments removed by you, Scrum Master? Ask this yourself.

Thursday, February 12, 2009

From Scrum to Taoism


Last noon when I was walking with Harri and he said that he visited a Taoist temple in Chengdu but both of us failed to figure out what the name of the temple was.
And then, I thought about Taoism and recognize that it is close to Scrum’s in some levels.

The most interesting thing happened next is that I heard Dr. Jeff Sutherland talked a little bit about Lao Tse's ideas in a clip on Youtube).

Anything you got from it? From ANN, Chemical process dynamics, Scrum, complexity adaptive system to Taoism…things are getting interesting.

Lin Yutang should refer to “林语堂”.

One of the core ideas of Taoism is action with inaction which influenced the ways to governor a country, manage a company ... and closes to the core of Scrum from managerial perspective. I'm not sure how further it could be used in Scrum management but sure about that there are quiet a few experiences on "action with inaction" ways to run companies, serve people...
Can we pull out something from it?

Wednesday, February 11, 2009

Metaphors between ANN and Scrum

Apparently there is no any relationship between a software development process (Scrum) and a computing process (ANN) at all. But I do find some interesting metaphors between ANN and Scrum.


ANN:::::::::::::::::::::::Scrum
Neural network--->Scrum team;
neuron---> team member;
weight---> teammate relationship;
Active function---> individual capability;
Problem space---> Product Backlog;
Solution Space---> executable software;
Learning iteration---> Sprint;
Learning Criteria---> Definition of Done;
Back-Propagation---> Retrospective;
Self learning---> Self management;
No analytic methodology---> No command-control;

What do you need to do in Scrum/ANN to get solutions?

design learning algorithm---> Customize the framework;
Design topology of the neural network---> Form the team;
Keep weights carefully---> Keep the team intact;
Define solution and problem space --->Define Product Backlog and Definition of Done;



Yes, there is no analytic methodology in ANN anymore. So does Scrum.

Don’t we try to solve the problems (software development) in sort of analytic ways in traditional process (e.g. waterflow process)? Moreover, we may take ANN as a heavily heavily simplified Scrum team (as it was supposed to be heavily simplified neural network). If we can think in this way we were probably closing to the fundamental of Scrum from different view point. And in return we may get some lessons or inspiration from ANN.

linchuan
----------------------------------------------------------
Hi Linchuan,

I am pretty impressed by your metaphor. It is very well explained and
crystal clear. I like it.
Maybe the parallel between ANN and SCRUM is made possible because both
are "empirical", as opposed to "theoretical" (traditional waterfall
process).
On this page, http://www.controlc haos.com/ old-site/ philsd.htm ,
Schwaber makes a distinction between the theoretical system
development method(the model can be predetermined in advance and
executed in a linear way) and the empirical one(where trial&error and
learning are part of the process that still delivers functional
products). From the later definition both SCRUM and ANN (with the
crucial importance of the learning phase) are empirical.
So your metaphor is, in my sense, also made possible because of the
theoretical/ empirical distinction.

Just my 2 fen! (in China we do not use "cents"...) ;)

Julien.
----------------------------------------------------------

yes. we can also make similar metaphor from different perspectives. ANN metaphor is an evidence of that empirical doesn't mean chaos in any sense. And further more, empirical can be proved mathematically, e.g. ANN. The inventors of Scrum also mentioned we can found theoretic supports from process dynamics... But ANN works fine for me (i do not have many knowledge on process dynamics). And i believe that sort of theories on chaotic and complex system should be the rock base of Scrum (or ANN or process dynamics ...). I'm not going to move too far on theory of Scrum (some body may). ANN metaphor can give us some guides or clues on how to use empirical method to solve problems.

Some software project managers, as far as i know, feel uncomfortable (or confused) with the new role in Scrum (ScrumMaster). Some said there is less job for PM or I do not know what i can do expect maintaining a few backlogs, apparently everyone can do that . As you can see in my metaphor, it is not true at all. There is a lot of things to do for a ScrumMaster or ScrumMster of Scrums (usually can refer to PM in traditional process). But you have to change the way you do it. And the new role is more challenge than PM in traditional project management practices rather than trivial for everyone.

Is it easy to design and implement a working ANN to solve a practice problem? Although ANN looks very simple.

linchuan
----------------------------------------------------------
Hi,

Interesting analogy. Is there any link between ANN and CAS
(Complexity Adaptive System), where inspection and adaptation come
from?

Though, i would NOT think of Scrum Master as Project Manager in
agile mode, rather, the traditional Project Management is
distributed into all Scrum roles - Product Owner (content, schedule
and budget), Team (self-managing) , and Scrum Master (removing
impediments) .

-Yi
----------------------------------------------------------
I strongly agree with you that ScrumMaster is NOT PM (job title). In practice, some PMs(hierarchy title) will take ScrumMaster role, especially ScrumMaster of Scrums.

So it is what i was trying to say with " a ScrumMaster or ScrumMster of Scrums (usually can refer to PM in traditional process)" .

linchuan

Scrum Tea is online

This blog is intent to have a place holding my thoughts, experiences, observation and lessons on Scrum software development process.