Usage of Tool in an Offshore Scrum Meeting

I have posted the following article on my new blog Agile offshore blog

There are number of ways how a team can conduct Scrum meeting in an offshore environment.

It is always recommended to have the answers for the 3 questions ready before attending the Scrum meeting. In an offshore environment, the Product owner sitting onsite(Ex:Australia) may not be able to attend the offshore scrum meeting (Ex: India at 10 Am in the morning) due to time differences. Sometimes, even though PO is able to attend the scrum meeting, he/she might have issues w.r.t language and accent (Ex: between French and English speakers). Such situations have taught us that, usage of tools like a scrum logger would benefit both the onsite and offshore teams.

The offshore team can make use of some tool to input the answers for the 3 questions on a day to day basis before getting into Scrum meeting. The onshore customer (who is having issue with accent or language barrier) can go through the answers daily and can get to know the impediments or any other issues without being a part of Scrum meeting.

The above scenario has been given keeping in mind that only the offshore team is part of development and the product owner is sitting onsite.

Servant Leadership and Chanakya

The servant leadership, a type of leadership development coined by Robert GreenLeaf is one which is referred the most in Scrum community. The Scrum Master is supposed to be a servant leader. Recently, while I was going through Wikipedia, I came to know that, servant leadreship is not a new concept and this concept existed even as early as 4th century. Chanakya or Kautilya, strategic thinker in India has advocated this concept in his books. As per Chankaya

the king[leader] shall consider as good, not what pleases himself but what pleases his subjects [followers]". He argued that "the king [leader] is a paid servant and enjoys the resources of the state together with the people"

Agile, Wiki and Trust

Is there any relation between Wiki and Trust ? I know it is difficult to believe, and it is true that there is !! Many organizations and teams use Wiki just as knowledge management tool Or a collaboration tool to share information across different teams spread across geographical regions. But this tool is much powerful than just a knowledge sharing tool.

The information that is shared in this tool shows the trust, the PMs have with their development team, the trust, the customers have with the software services vendor, and the top management has with their employees.

Consider that, you are an employee of a company in sales/marketing division. Can you put the day to day activities of the prospective customers you met that day, the discussions what you are having with the various customers, status of various accounts, etc in Wiki. Why not ??

If you are not doing this, it is mainly because you want to protect your customer information from getting into your neighbor who is another sales/marketing guy. You might be worried that somebody might steal all this information. You might be worried that your information would expose some of your weaknesses in handling the customers.

Consider that you are a developer in a software services firm, and can you put all the problems(as in roadblocks, to achieve goals) you are facing in your project on official wiki ? Why not ?

If you are not doing this, it is mainly because you are worried about exposing the problems of the project to public, customers and to the management and, the finally the consequences of getting thrown out of the project.

In each of the above cases, one of the main problems is the lack of trust within the team and across teams.

As we are aware, Agile methods would succeed only in an environment where people work together with no fear or favor and with trust. Now, coming back to wiki, the amount and type of information you put on wiki without fear or favor decides how much trust is present in your team and as a whole in the organization.

I have seen many organizations having a wiki with access control. It is not bad, especially in a software services firm, while working with multiple customers, NDA would force the organization to mask information from each other. But restricting access to public domain information shows the lack of trust.

If you have read Maverick , you would understand that Ricardo Semler even goes ahead and exposes the company financial information to all employees. Initially the senior management gets worked up and starts worrying about the possible leak of financial data to competitors by employees. During that time, Ricardo asks something like,

if you don't trust your own employees, why did you hire them at the first place ?

Applying Agile/Scrum practices in Maintenance projects

In many Agile training programs and conferences, common question that gets raised is, does Agile/Scrum works in maintenance projects ?

I always say "YES" and the team needs to tweak Or invent the practices to suit their needs.
Maintenance projects could be enhancement projects OR pure defect fixing projects.

Enhancement projects involve new set of development over existing one. Since the developers gets new set of requirements at the end of each iteration, one can apply the standard set of Scrum practices with little or no modification.

Defect Fixing projects involve fixing defects on closed or current projects not in development. Sometimes these projects are boring, especially if a new team has been hired for defect fixing purposes only. The customer sends a set of defects on a daily basis or weekly basis with a deadline to deliver. The development team needs to fix them ASAP and send the patch for further testing.

While coaching one of such a defect fixing projects, I found that the following Scrum practices can be applied without much modification
1. Daily Scrum meetings
2. Scrum of Scrum
3. Modeling days while solving complex defects
4. Information radiators displaying InProgress, completed, reopened, closed defects and other information
5. Usage of Wiki for collaborating with the customer
6. Requirement workshop while understanding complex defects
7. Review and Retrospective

Common problem that I have found in defect fixing projects include, setting the iteration length. Especially, if the defects are given on a day to day basis without prior knowledge of what you are going to get, it makes the life of the development team bit difficult.
This can be solved by collaborating with the customer and coming up with a plan to have 1 or 2 weeks of iteration length.

Agile Offshore Development Tip 4: Involve Offshore into Scrum meetings

I have seen distributed teams following Agile practices but each one not really sharing information with other distributed teams. For ex: Both onsite and offshore teams would be conducting Scrum meetings but skipping Scrum of Scrums.

Important thing in distributed Agile development is to include the offshore teams for all important workshops. For ex: Requirement, Retrospective, Modeling days, Iteration planning meeting.

In many onsite-offshore projects, the onsite team handles the design/architecture part and the offshore team is involved in pure development and testing. This model makes many onsite teams don't feel like involving offshore teams for Requirement workshops, modeling days.
Which in turn leads to a huge communication gap and would result in creation of a poor quality product. The above mentioned scenario would also involve lot of hand offs from onsite team to offshore team, resulting in lot of wastes being added to the system.

Systems thinking needs is the key to succeed in distributed Agile development.

TestSuites should be on Feature Themes

Many developers tend to package TestSuites to contain the tests based on technology/layers. For ex: TestSuites to contain the tests on UI layers, Dataaccess, BO.

Since we create unit tests to test a unit of functionality, the TestSuites should contain tests based on the Features/Use cases.

For Ex: TestSuites to contain Unit tests testing feature to add User Or Modify User.

Task creation for fulfilling user requrirements

At the end of the requirement workshop, first thing the Scrum team would be looking forward to is to create the tasks for the features. For the rest of the iteration, only thing they are worried is how many tasks they have been able to complete. In this process, they forget that they have to deliver the Running Testing Features(popularly known as RTF) to the customer.

One way to avoid this task creation madness could be to divide the features into smaller feature chunks that can be handled like a task. (Right now the discussion is going about this in scrumdevelopment forums)

For Ex: instead of writing a task like "Database creation", if we can rewrite it as "Database creation to fulfill the storyX" Or rewriting it as "Handling Database related work to fulfill FeatureX" could make the team to "NOT" lose their focus on features/requirements.

Applying TDD while dealing with database related actions

There are numerous thoughts about how to go about applying TDD while dealing with database access related code. Some of the common thoughts include

1. Replacing DB with Mock Objects to simulate Database
Most preferred one. Advantages include

• No need to worry about DB info, driver info,
  
• tests run faster as compared to other techniques
• No need to change any test code because you changed the database
• Easier to maintain
  

2. Using a local copy of DB
Some programmers suggest to make use of a local copy of database for testing purposes. It has its own pros and cons:

• One needs to be aware of local Database related APIs
• Keeping the local copy of DB in synch with central test DB is bit tricky, especially with a large project team.
  
• Easier to use
  

3. Use central test DB
In this case, test with the cental DB, and apply transaction/roll backs to clean up DB after the use brining the DB back to its original state

• You can be confident that your code works well with the DB
• goes against some of the unit testing principles created by thought leaders like Michael Feathers
• Easier to maintain and use
• Be aware of Database APIs, drivers, etc .

4. Use an in-memory DB (like HSQL) Or any other faster databases

Not recommended much

• Again this goes against unit testing rules
  
• easier to use
• You are not sure whether your SQL queries tried against in-memory DB works with real DB
  

Group Thinking clouds decision

Recently I read this article, "Group Thinking Clouds Decisions" on live Science.
"http://www.livescie nce.com/humanbio logy/070221_ friends_memory. html

As per the above research, "People have a harder time coming up with
alternative solutions to a problem when they are part of a group, new
research suggests." and also, "When a group gets together, they can
miss out on good options,"

As agile practioners we encourage people to come together and make decision as a team. I am not sure, what is the impact of above research on Agile practices. I have put this question in Scrum development discussion forum, and one of the respondants came back with the following response

There is a natural tendency for groups to seek a sort of median, but
with a group of exceptional people, that can be a fairly high mark.
A single study does not decide much in science


Even I am not sure of the impact, but time could decide !

Agile Retrospective meetings for new scrum teams

Retrospective meetings are the heart of agile methodologies. Scrum teams follow this religiously at the end of each iteration.

When a team starts practicing Agile methodology, how should they conduct the retrospectives, what should they cover during their first retrospectives ?

Here are my thoughts
1. Take the help from an agile coach if you are doing the retrospective for the first time

2. Do the +/Delta analysis for the time already spent on the project in the past i.e. cleanse the past !. This session might take anywhere between couple of hours to a day, depending on how large the past is. Let the team select important times lines from the past(release dates, company meetings, customer visit presentations during project kickoff,etc) and create +/D for those events. At the end of retrospective, the information can be merged together.

3. Let the participants spend some time on thinking about the past events before attending the retrospective meetings. Let them have a brief summary of things that went well, and didn't go well and things to improve. This would save some "thinking" time during retrospective sessions.

4. If the managers are coming from command and control background, it would be better to do a separate retrospective for managers and development team. Read Diana Larsen's book on Agile retrospective for further information.

Semantic Diffusion

A nice article by Martin Fowler about thoughts, trends and future of Agile. He discusses the topic, if Agile just a buzzword ? where are we right now ? Are we on the right track ?

Testing Private Methods

Testing private methods was posted here

agile Vs Agile

Here is a nice article on Agile Journal trying to differentiate between Agile Vs agile

Traditional Planner Vs Agile Planner

How do you differentiate a traditional Planner Vs Agile Planner. Here are some of my thoughths about them.

Traditional Planner during planning

• Considers that the developer works 8 hrs per day.
  
• Allocates tasks to the development team and allocates features to fit into 100% of resource budget available

Agile Planner during planning

• Takes Ideal Engineering Hours (IEH) into account. It could be anywhere between 6 - 61/2 hrs per day (from my personal experience)
• Allocates tasks only between 70-80% of the resource budget available. For ex: if there are 6 developers working on 2 weeks iteration. He would then plan for 70% of (6 * 10 d * 6 IEH). (ofcourse, keeping holidays, planned leaves into account)
  

The 70-80% buffering is context dependent. Even though there is no standards available, Mike Cohn suggests, 70% of the planned effort needs to be targeted. There are various techniques to calculate the size of the buffer, and one of them quite often referred by Mike Cohn is "Square root of sume of squares" approach. I felt this is too mathematical and complex to apply during planing and many people have felt it is time consuming.

I have created a rule of thumb, if the iteration length increases, then the buffer needed to handle uncertainty needs to be increased accordingly.

I have tried with 80% planning in a 2 week iteration period, and it worked well.

One of the columns in Product Backlog(PB), we have been using at Valtech is "MoSCoW rule". This rule is extensively used in DSDM community. This column is being used to prioritize the requirements. These rules are very handy and easy to understand, as comapred to "High, low, Medium" Or "1, 2 and 3" numbers. It is advisable to fill 70-80% of the PB with Must Have requirements, and the rest with Should/could have requirements. Customer needs to be made aware that, if new tasks get discovered during iteration, the 20-30% of lower priority(SCoW) would be dropped.

More info. on MoScoW rule is available here

Tips during Requirement Workshop

While I was coaching one of the teams on Requirement workshop at Valtech, I jotted down some ideas, and here they are:

1. Once the feature team completes their "Questions", "Assumptions" part , ensure to do the Show and Tell exercise

2. During Show & Tell (ST) exercise, ensure to remove the duplicate questions/assumptions immediately as soon as they are found. This would help the team to consolidate in the end

3. During ST, If anybody in the team answers the questions(from the questions column), and found to be accepted by others, move the same to "assumptions" section.

4. If you are working on UI related application, keep the mock or prototype of the screen handy. This would immensely help the teams to visualize validations/screen structure, etc

Features and Tasks

I have seen many programmers getting confused between Features and tasks. Features are going to be part of Product Backlog and Tasks, are added by the developers into iteration backlog.

Features/Requirements are given by the Product owner. Iteration Backlog should contain only those tasks that would add value to the customer. There are certain tasks that need not be mentioned explicity. For ex: Refactoring, if you are following TDD.

It is assumed by default that Refactoring is going to be part of TDD(TFD + Refactoring). But, until the team gains profeciency in this area, they might have to explicity mention it in iteration backlog.
Similarly, Unit testing. If you are following TDD, then adding a task like "Coding..." would imply by default that, unit testing is done.

Nice Article on Agile Contracts

Here is a nice link on various types of Agile Contracts (Fixed Price, T&M, etc)

Software Development Vs Construction of the house

A house is being newly constructed in front of my house. I have been watching this from the last few weeks. One day, I saw the owner with the architect at the site discussing about something for a long time. I am assuming the owner was trying to explain his requirement to the architect. After few days, I could see the plan with the architect and he discussing the same with owner and making corrections. After a while, I could see some construction workers starting their work by digging the foundation, building the house wall by wall. I know that this is pretty much the same process everywhere no matter where you are. Most of the time, the house gets constructed within the budget and within the time.

I was wondering, why can't we follow a similar process in Software development. In software too, we have the product owner, architects, etc. Why can't we deliver the software within the budget and on time (atleast 50% of the time).

I know we can't in software, here are some of my thoughts:

1. During house construction, there is mostly freezing of requirements during the initial stages

2. In waterfall model, freezing of requirements was tried and we know it was a failure. In agile methods, we tend to keep this open and ask the customer to prioritize and give the requirements.

3. Advantage in software development is, the customer can change his requirement at any time. So, there is a huge responsibility on the software architect to have a flexible architecture.

4. During house construction, since the requirements are frozen, there is a little room for the owner to change his requirement once the foundation is laid. It does not mean that the customer should not Or cannot change. But the key point to note here is "Cost of change" in house construction is more than in software development (assuming robust architecture is in place !!)

Good Books on Agile

Here is the list of some of the good books on Agile software development and related areas. I am hoping to keep this list updated:

1. Agile and Iterative Development by Craig Larman
2. Agile estimation and planning by Mike Cohn
3. Extreme Programming Explained
4. Test Driven Development by Example
5. Pair Programming Illuminated
6. Agile Project Management with Scrum by Ken Shwabber
7. Agile Project Management by Jim Highsmith
8. User Stories Applied by Mike Cohn
9. Rapid Development
10. Crystal Clear
11. Goal
12. Critical Chain

Scrum Vs Traditional Project Management

Here is a nice article comparing Scrum with Traditional Project Management