Monthly Archives: September 2013

How to avoid building Non-Self-Organizing Teams

A true Agile teams should be “Self Organizing” one.  The Agile principals states that “The best architectures, requirements and designs emerge from self-organizing teams”. Considering that statement true, every manager would like to have such a team, because architecture, design and knowing the requirement well are the building blocks of any product and the superior they are, more the chances to build a better product. As we know that change never stops, it’s a constant process, projects and teams are not an exception, they also suffer because of constant changes and have to strive hard to deal with it and be continuously in the process of being self-organized.

It’s difficult to list the characteristics of a self-organizing team because there are so many of them; so instead, we take an inverse approach and use a list of characteristic of a non-self-organizing team. If any of following exist in your team, you have to take an action to avoid such practices to become a self-organizing team.

Characteristics a Self-Organizing should not have:

  • When an issue comes team members wait for instruction from manager.
  • Team does not know exactly what adds value to the company.
  • Team manager assign work to the team.
  • Manager randomly initiates meetings to discuss issues and feedback.
  • Team members resist in helping other team members.
  • Team members claim ownership of their code.
  • Goals of project, release and iteration are not clear to the team.
  • Individual performance is more important than team performance.
  • Team is more concerned about productivity rather than adding value.
  • Team wait for instructions and commands from the management.
  • Team lead is assigned by management.
  • Team members rarely ask question to explore more about the product and try to confine to the information provided to them.
  • Team work in silos, privately and not share a common place.
  • Team member don’t express their opinion in the meeting regarding issues, ideas and opportunities.
  • Individuals instead of teams are held responsible or rewarded for any failure or success that is sign that team lacks collective team responsibility.
  • Team collaborates rarely with the customer.
  • Teams are not mentored and taught on the regular basis to improve their self-organizing skills.

Words of Caution:

There is a big misconception around the concept of self-organizing teams. Many times people assume that self-organizing team are not managed or controlled. That is not true; although agile self-organizing teams get more freedom and participation in their work as compare to traditional teams but they are still need a lot of guidance from management. The truth is that now self-organizing teams are not supposed to be “Micro” managed, they are encourage to participate more in the project and take ownership and responsibility of the project.

Another misconception is that a team becomes self-organized as soon as they are named or titled as self-organizing team. In fact teams need to be trained extensively in the beginning and continued to be trained though out the life of the team to become and remain self-organizing.

Author: Mobeen Siddiqui, Provides Agile coaching services in Minnesota, particularly in greater Minneapolis area.



List of Continuous Integration Tools


List of Continuous Integration Tools

As Continuous Integration practice is becoming more prevalent among the agile teams, the more and more continuous integration servers sprouting up with new features. Many readers want to know the list of continuous integration servers available so here I am publishing a list Continuous Servers available in the market. I have seen that most popular among paid ones (hands-down) is Jenkins followed by Bamboo, but there are others very feature list free servers are also available to use.

Before selecting a CI server, we need to see which tool fulfills our needs more effectively. Every team has its own needs and requirements and every tool offers different feature set . Following is a list of most common features would like to have on their CI tool.

  • Easy setup
  • Available plugins (findbugs, emma, coberturna, yodiz etc.)
  • Distributed builds
  • SCM trigger integration
  • Issue tracker Support
  • Support documents/help/customer service
  • Is it alive tool, new features are coming?
  • SCM Support
  • Allow to create repositories
  • Multiple SCM support
  • Support Parallel builds
  • Distributed builds
  • Force builds
  • Notification process i.e. notify when test fails
  • Authentication
  • Build tools support (Ant, Maven, n ant)
  • Test Rendering (nunit, junit etc.)
  • Role management
  • Language it is built on

Free or Open Source Continuous Integration tools



Free/Open Source

Anthill Y
BuildBot Y
Cascade Y
CI Factory Y
Continuum Y
CruiseControl Y
CruiseControl.NET Y
CruiseControl.rb Y
Easycis Y
Gitlab Y
Gump Y
Hudson /Jenkins
OpenMake Mojo Y
RedJack Y
Sin y
Tinderbox & Tinderbox2 Y
Tinderbox3 Y
Travis Y
X-inc Y


Paid Continuous Integration Tools




Free/Open Source

Anthill Professional N
Bamboo N
Circle CI N
Cruise N
easyCIS N
ElectricCommander N
FinalBuilder Server N
OpenMake Meister N
Parabuild N
Pulse N
TeamCity (EAP) N
Zed N
Team foundation N
Luntbuild professional N
OpenMake Meister N
OpenMake Mojo N


Author: Mobeen Siddiqui, Provides Agile coaching services in Minnesota, particularly in greater Minneapolis area.



Agile Best Practices


Agile Best Practices

What persuades me to write this blog is the question which I face every now and then, that is, what are the best practices of Agile or Scrum methodology? Though I respect the curiosity and enthusiasm of learning best practices of Agile but at the same time I would suggest to first know the principles and manifesto of Agile. By knowing the Agile principles well, teams would in-evidently or evidently not only adopt but also come-up with the best agile practices for the team.

In reality there are so many Agile best practices that you might need several pages to cover them all, but based on my experience I can write down a few which I witnessed to be used by many successful agile teams. It does not concur that these are the only Agile practices that Agile teams should adopt to be successful. It only suggests that following are a few important best practices which if implemented correctly may help team to be successful.

1.       Creating Effective User Stories using INVEST

In one of my earlier blog I mentioned what are user stories and how those need to be created using INVEST acronym. If you have any difficulty in writing a user story, this blog may help you to write effective user stories. Writing user story by using INVEST acronym is considered one of the Agile best practices because of the each letter provide following benefits to the team.

-          Independent: It assures that each user story is independent business requirement.  Since there is no direct dependency involved in implementing the user story, a team is free to choose any user story to implement in any order.

-          Negotiable: In agile stories are just like wishes. This is something customer wants to have, but it does not mean that it can be developed easily. Developers get the chance to discuss user stories with the product owner. That discussion is what help teams to understand the requirement in detail and it also gives some insight to the product owner regarding complexity involve in developing the user stories. That discussion may also lead to a better and easier solution for same wish.

-          Valuable: It should be clear from the story that it produces value for the customer. When development team to understand the value a user story is adding for the customer, it becomes easier for them to prioritize and test the user story.

-          Estimable: User stories should be written in a way that team could easily break it into tasks. When divided into tasks team can easily estimate the time it will take to complete a user story. Following is an example of bad user story that is not estimable and need to be further divided into smaller user stories

A Bad User Story: <As an owner, I want to have a portal, so I could sell my product online>

-          Small: It gives team a chance to have discussion on the user story and divide them into smaller user stories and join them with another existing user stories if needed. Usually user stories are of maximum 40 hours of work, user stories bigger than that should be considered to be divided into smaller user stories.

-          Testable: The INVEST criteria make it obligatory for the author of user story to write the test and acceptance criteria of the requirement, which removes ambiguity for the developer pertaining functionality of the feature.

 2.       Daily Stand-up Meeting

The Daily Stand up meeting is a way to let team members know the overall progress of the project, after the standup meeting every team member is aware of the work being performed and impediments faced by other team members.  Just in 15 minutes whole team come to the same page in terms of progress of the project. It also provides a platform where team huddle before start of the day and if needed offer help to other team members to resolve each other’s issues. Usually scrum-master knows the technical strengths of different team members and should assist them to coordinate and collaborate with each other.

 3.       Assigning Spike

Agile supports and recommends time-bound iterative development. Before start of iteration, the team has fixed and prioritized user stories to work on. Teams don’t always have the knowledge of implementing every user story or task, sometimes team have to explore to find out the best solution for the problem or requirement in hand. In such cases some time is reserved for the team to research and find an effective and sound solution, which is also called a Spike.

More often than others spikes are used to find an architectural solution of the system. Not assigning enough Spike time can have severe implications. I have seen teams who selected the technological solution in haste, without performing enough research to find the best solution, which cost them an arm and leg in later stages of the project.

4.       Test Driven Development

In test drive development you test before you program. That sounds little non-traditional, you may question how can you test before you write code? The opinion on TDD differs and opponents and supporters both have valid points to support their view but based on my vote goes to TDD. The only caveat is that team should be properly trained to write good TDD and time should be given to practice TDD. Once gets proficient team started to give result. It tremendously helps team to create code that is less error prone. In long run it improves the quality of the code and cut time of bug fixes and refactoring sessions.

5.       Refactoring

Refactoring is an important agile practice, and developers should always be cognizant of it all the time. It’s not necessary to assign a specific session or time for refactoring the code. Code can be refactor while you intend to do something and finds out that same thing can be achieved without changing the behavior of the program in much less code or code can be more organized or there is a better,  smarter, safer way of doing same thing. As mentioned earlier in agile development quality is everyone’s responsibility. So by doing refactoring developer help team to improve the quality of the code that helps the project in long run. Agile principle, “Continuous attention to technical excellence and good design enhances agility, reminds us the importance of refactoring.

6.       Continuous Integration with Automated build/time controlled

If you are not aware of what continuous integration is, you may like to read this blog. The Continuous Integration has been quite prevalent now; many teams have already realized the importance and benefit of implementing CI. By implementing CI team ensure that they their product is ready for release, anytime. Also for many teams it is center piece of their QA, because it acts as first check post to stop errors and issues.  CI goes along with automated build and automated testing, which is another best practice of agile development. Early adoption of CI increase quality and reduce time for development for expert teams.

7.       Unit and Exploratory Testing

In Agile development quality is everyone’s responsibility. As part of improving quality developers are advised to write unit test with the code. By writing and running unit tests on developer’s machine chances of slipping of errors to production code gets slimmer, and ultimately improves quality of the code.

 8.       Automated Testing

Automated testing saves an agile team a ton of time. Automated testing is part of continuous integration, as soon as code is integrated; it is automatically tested and built. It’s also important to know that you got to be selective in choosing tests that need to be automated. The tests that are performed only once or twice should not be automated. Finding the right balance between automated and manual test plays an important role in efficiency of overall testing.

 9.       Task/Release/Issue and Planning Boards

Almost all the tools use Task/scrum boards to move tasks from one progress state to another. It’s really helpful to drop and drag a task from one stage to another and sort them with different filters. Based on my experience same drag and drop experience can be applied to Release, Issue and planning board. Yodiz is one of the agile management tool which provides unique board experience. I think using these boards give more visibility and transparency of the work performed.

10.   Velocity/Burn-down/Burn-up and Reporting

It’s very widely use practice and most of the agile teams understand and use the Velocity and burn-down/burn-charts to measure the progress of the project and to estimate and readjust teams goals. If needed my previous blog on velocity and groomed backlog can be accesses here. Over the time period velocity of the team usually gets stable and predictable, which helps teams to plan and estimate future releases more accurately.

11.   Sprint Retrospectives

Agile principle, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”, reminds us that an Agile team should reflect back and see what mistakes were made during its last iteration and how to avoid them in the future, or what processes or practices were great and what other ones did not work for the team. The whole team gives its input in such retrospective sessions. Especially scrum-master keep an eye on all the things which did not work that great and should be able to initiate a debate that how can we as a team improve our efficiency.

 12.   Cross-Functional Team

A Cross functional team is supposed to include members who have all necessary skills needed in the project. When you are working on a project you might need an excellent Java programmer, an architect with SAS experience, programmers who also know how to write the Unit tests and a tester who knows how to automate the tests, an infrastructure specialist who knows how to setup the integration server for CI. It’s responsibility of the project manager to make sure that all people with required skills are present in the team. Agile is time-boxed development, team members with good mix of skills help to complete their work within the specified time without depending on someone outside of the team. My experience is those self-sufficient teams are more successful in terms of completing their project in time.

13.   Self-Organizing Team  (principles)

There is a lot of confusion around the concept of Agile self-organizing teams. One thing that needs to be cleared is that self-organizing teams are not meant to be same as completely self-managed ones. So question is what are self-organizing teams? The self-organizing teams are those teams who take responsibility of the work they choose to perform. It is important for all the team members to understand what does really it means to be an empowered team. The old saying “With great power comes the great responsibility” perfectly fits in this situation. It’s role of the management to transform sense of responsibility with organization vision to the team. The more self-organizing an agile team gets more effective it becomes, but team don’t become self-organizing themselves. Its responsibility of the management to set the processes in such a way that team could learn how to become self-organized. Team participation in decision making, estimation activities, retrospective session and stand up meeting should be organized in such a way where team are given freedom to give their opinion and take responsibility of the decision made based on their opinion. Scrum master and agile project manager still manage the team but they don’t micro manage them. The task is to let the team understand the goal and vision and let the team product the results without much interruption.


Author: Mobeen Siddiqui, Provides Agile coaching services in Minnesota, particularly in greater Minneapolis area.

Agile User Stories and Groomed Project Backlog – with Examples

What is a User Story?

Agile is a value based development methodology, where all those features of the product which can add value to the customer are recognized, prioritized and developed based on customer needs.  These valuable features are best described in users own words. Hence finding out who are the users is an important task. Once all the users are recognized, requirements which add value to the user are written down considering the needs of those specific users. Since those requirements are coming keeping users in mind, they are called User Stories.

How to Write a User Story?

User Stories are best written in following format.

As a <User>, I want to <Have> so that <Benefit>

Here user story describes how a user (a manager, a clerk, a developer, a librarian, an owner etc.) will want to interact with the system and get a certain benefit out of that interaction.

User –a user is the user of the system

- a manager
- a clerk
- a developer
- a librarian
- an owner etc.

Benefit – Benefit is the value a user will get of the system.

-  a manager can see the audit report in one click, which will save his time.
-  a clerk could search a report, which will save his time.
-  a librarian could search a book by category, thorough which he/she will improve customer service.
-  an owner can order an equipment, which will save him from hassle.

By writing user story in this way, it’s easier for the reader to know who is getting what, to know that information helps at the time of prioritization, estimation and development. Also it opens the door of discussion between different stakeholders.

What are examples of User Stories?

Following are 25 sample user stories.


1.       As an administrator I want to able to create a new user to the team when needed.
2.       As a lawyer I want to see all my active cases on the main screen.
3.       As a student I want to see all of my old transcripts on the board.
4.       As a driver I want my GPS voice activated.
5.       As a researcher I want to see last few searches I made.
6.       As a user I want the ability to restore my password.
7.       As a cashier I want to see total amount in cash register displayed.
8.       As a pilot I want to know the best flight height to fly in current conditions.
9.       As a police officer I want to see the previous tickets given to a driver.
10.   As a post man I want to know estimated time to deliver today’s mails.
11.   As a guitarist I want to know speed of my fingers on the string.
12.   As a grass mower I want mower avoid hitting blade to hard things
13.   As a runner I want to be warned of irregular heart rate.
14.   As a blind person I want to be warned for a hard thing coming on my way.
15.   As a student I want to shuffle my flash cards.
16.   As a credit card user I want to be warned if spent more than a set amount.
17.   As a kid I want to turn off all the toys not active for a while.
18.   As a driver I want to be warned of the tire pressure.
19.   As a student I want to be reminded my class schedule every morning.
20.   As a manager I want to do what if analysis while planning.
21.   As a tester I want to see all the bugs assigned to me with status.
22.   As a ticket booker I want to be notified as soon as a ticket gets available on a full flight.
23.   As a writer I want my work get auto saved after every few seconds.
24.   As a reader I want to see list of most sold books in last 2 weeks.
25.   As a cook I want to see most visited recipes.


What is the term INVEST?

User stories are supposed to have certain characteristic described by Bill wake as INVEST.

I – Independent (stories should be as far as possible independent so each of them could be developed and delivered separately.

N- Negotiable (User Stories should discussable further and there should be space of negotiation)

V- Valuable (User Stories should result in adding value to the customer)

E- Estimable (User Stories should be understandable enough so could be divided into task and could get estimated)

S- Small (User Stories should not be too big, usually should be done in 40 hours of work )

T- Testable (User Stories, usually have acceptance criteria to test if they fulfill customer’s needs )


What information User Story may contain?

What is a Project backlog?

Once created user stories are stored in project backlogs. Project backlog is an important artifact of Agile; it’s a place where all the user stories are stored, usually by project owner. Project backlog contains user stories which are not estimated.

What is a Groomed Project backlog?

User stories placed in backlog are not prioritized and estimated yet. They might need more detail and explanation. Agile team may need to discuss more to fully comprehend not only the requirement but the value attached to the backlog. For that Agile teams take part in a grooming session, where user stories are discussed with the team and all the ambiguities are removed. Development team ask detailed question pertaining user stories and product owner prioritize them. Also development team and product owner estimate the user stories. After completion of grooming and planning session team comes out with a groomed backlog. Groomed backlog also represented by DEEP.

-          Detailed appropriately

-          Emergent,

-          Estimated, and

-          Prioritized

What is an Epic?

Epics are large user stories at relatively high level with LOWER PRIORITY. They are too big to implement in a single iteration and therefore they need to be disaggregated into smaller user stories.

Author: Mobeen Siddiqui, Provides Agile coaching services in Minnesota, particularly in greater Minneapolis area.

What is Continuous Integration?

Continuous integration

Agile development is widely adopted because it’s mantra of providing quality software in less time. It’s seems to be a win-win situation, usually when you put emphasize on quality you spend more time on testing and making sure that everything is working as expected. So question is how come Agile can provide you double triumph i.e. less time and more quality?

Agile achieve this efficiency by introducing better processes and practices. Continuous Integration is one of those best practices.

What is Continuous Integration?

As name suggests “Continuous Integration” is all about integrating code to the trunk/main-line as soon as new code gets ready to be merged.


As a programmer have you ever been in a situation when you integrate your code to main line (trunk) and it failed with ton of errors? It’s a very common situation, particularly in a team where multiple programmer are working on same code and you check out code for a longer period of time and check in your code back to the main-line considering your code will not clash with other programmer’s changes. In reality project code is much inter-connected, many people using same base classes and database connections, common objects etc. When situation like these occurs you may spend hours and hours to fix the dependencies and error caused during between your check-out and check-in.

To avoid the impact of such situations, you can integrate code frequently, by committing early you find out the code differences early as well and you don’t have to spend much time to resolve the code conflicts. By integrating and building code for every single change made to the code help to improve the quality of the code and finds error as soon as it occurs.

To understand the Continuous Integration, you must know the concept of Version Control System. CI process updates the current version of Version control system, the current version is also called Trunk. To know more about version control system Click Here

How it works: Following steps show how CI works.

1-      Check-in code from trunk.

2-      Make the changes in your local copy.

3-      Run the unit tests locally.

4-      Run a local build.

5-      Check if the local copy after changes matches with the Trunk? If it does not match merge the updated code from Trunk to local copy, and repeat step 3-5.

6-      Commit, i.e. merge your code with the copy of mainline.

7-      Build the code. It can be done on a build server.

8-      Run test on the server.

9-      Deploy code to the server.

In above steps you only move to next step when current step is successful.



What happen if two programmers make changes to the same code?

When multiple developers work on same code, it is not uncommon that first developer makes changes to the code and merges it to main line. After some time second developer also make changes which make the build failed. In such situations it’s responsibility of second programmer to find out the dependencies and conflict in the code and make changes to the code with consensus with other programmers to make the build successful.

Is Continuous Integration must be adopted to run an Agile project?

No. The continuous integration is one of the many best practices of Agile development, and It’s evident that it’s usage helps to reduce possibility of bigger problem which could occur if code is not integrated frequently. But it is not necessary to adopt CI to run an Agile project. Over the years we have seen many successful Agile projects where CI was not adopted.

What is integration machine?

Integration machine or integration server is a separate server which is used to run a build of the newly added code to the trunk. Code from the version control system can be copied to integration server manually and once copied a build is run.

Author: Mobeen Siddiqui, Provides Agile coaching services in Minnesota, particularly in greater Minneapolis area.