Many people quest for the best agile project management tool in the market. If you browse through websites of agile tools, almost all of them seem to offer similar features that can make quest even difficult. First of all “the best agile tool” is very relative term. Every Agile team is different; its dynamics, culture, needs, demographic and many other factors can play an important role in selecting a suitable tool which could fulfill majority of team needs. So you may have to try a few of them before deciding which on suites your team best.

Let us take some of the basic features or qualities you should look at before selecting a tool for your team.

1) UX/UI

UX and UI are vital factors in selecting an agile tool. The tool you select should be able to support to perform all the user story and bug management related actions quickly and smoothly. The feature that may improve may involve following actions.

-          Inline User Story/Bug creation

When planning is in full swing, during the release planning and sprint planning meetings you got to perform certain task quickly and one of those tasks is User Story and Bug creation. Having the tool which does not support inline user story and bug creation could make the whole planning process quite cumbersome.

-          User Story/ Issue Search

At times as an agile tool user you may need to look for a specific User Story, tasks or issue. Without having an efficient search available it may take you long time to find your object of interest. Preferably search should be available on all the pages and should have option of searching using different criterion such as Search by US ID, Bug ID or Task ID etc.

-          Filtering and sorting

When you are working on a project you might prefer to view the items in certain order. It’s a must have feature of an agile tool. Your tool should be able to provide you enough filtering option to cover your needs; it could be filter by severity, status, personal responsible for, priority etc.

-          User Story/Bug Status change

There are certain actions which need to be performed many times a day, and changing status of user stories, bugs and tasks are a few of such actions. You should be able to perform these actions easily without making an effort of too many clicks.

-          Multiple Person assignment

In real life user stories and bugs are assigned to some specific person of agile team. Depending on the complexity of the problem or user story, you might want to assign multiple people to a user story. Your tool should able to support this commonly needed feature.

-          Changing severity and priority

We sometimes need to change the severity or priority of an issue or user story, your agile tool should be able to provide the functionality of changing the severity of a user story or bug without making too many clicks.

-          Estimating/Sizing

As mentioned earlier that an agile tool should support inline user stories and bugs creation. You may also like to size the user story in-line with minimal effort. That makes a huge difference during your estimation sessions, you don’t want to open each story or bug in a popup and close it and open next one you want to size, agile tool of your choice should provide you possibility of estimating user stories or bugs in-line, and that for sure save a lots of teams valuable time.

-          Reporting

There are certain measures that keep you cognizant about the progress of the project and the team. Such measures are supposed to be visible to entire team. For example velocity and burn-down/burn up charts are examples of such measure. They are also called information indicators and agile tool should make them visible to the team.

2) Secure and Reliable

You need to know the level of your agile tool security. The last thing you would want is to see your data wiped out. Make sure that cloud service used by the tool has up time above 99%. Worst thing would be to wait in your planning meeting for your tool to be up.

3) Collaboration

Agile’ s manifesto states that it values Individuals and interactions over processes and tools, and when your team is not located at one place you need to have a tool where you could interact with each other effectively. Having a chat tool is one thing and having a tool that helps you save your discussions with the references is another. Preferably an agile tool of your choice should have project based and groups based chats available to help team and groups to make your communication personalized.

Discussion module and wiki is another feature that might help to improve communication among your team members.

5) Notifications

You want to monitor the progress of a particular user story which is very important for you, or particular high priority issue. You need to be notified for any status change made to the user story or bug of your interest.

6) Reporting

As a product owner, scrum master or even as a developer you want to see the progress of ALL the projects you are linked to. Do you want to see # of US, bugs, # of critical bugs by sprint or by release and by many other criterions? You need to make sure that your tool provides comprehensive reporting at project, team, and program level.

7) Issue Tracker

We have seen many teams which are using separate issue tracking system with agile tool. Ideally your Agile too should be able to handle the bugs as well. Having issue tracker within agile tool saves ton of agile team’s time. Agile encourage continuous interaction with the customer to get frequent feedback that also brings a lot of changes and issues to be fixed for the team. An agile tool with a good build-in issue tracker not only saves time and money but also reduce complexity for your team.

8) Integration and Import/Export

Before deciding on a tool, make sure that it allows you to import data from other system and let you take (export) your data out of its system. Also your agile tool should provide you to interact with other commonly used tools such as Github, SVS, Pivotal, Jira, Dropbox, Box, Conceptly, Uservoice etc.

9) Customer Service

Last thing you want is to wait for the customer service response when you really need help. Our experience shows that not many tools have great customer service. Before making the final decision, try to contact with the support team of the tool and see how quickly and efficiently your query is answered.

Best Agile tools in the market

Based on our criteria above we tried many agile tools and came up with the five best in the market.

Yodiz – The best All in one agile tool, includes issue tracker, chat and 3 free users. Check price here.

Rally – Good training services and material. Check price here.

Version One – A lot good training material. Check price here.

Jira – Provides good integration with other components such as Jira, Bambo etc. Check price here.

Pivotal Tacker – Lite version does not have enough features. Check price here.

Author: Mobeen Siddiqui – PMI ACP

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

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

Paid Continuous Integration Tools

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

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 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.

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.

Problem

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.

Questions:

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.

Stand up meetings are extremely important to Agile projects.  Face to face interaction between all involved in the project is key to knowing what everyone has completed, what they plan to work on that day and what challenges they are working through. I know what Ken, Adam, Sara, Ali, Mark and Anita are working on, also I know what kind of problem each of them are facing through my daily standup meeting (15 minute meeting happen every morning). In stand-up meeting we all describe what we are working on today, what we worked on yesterday and what kind of issues we are facing to accomplish our task on time. After the meeting, I start working on the task I chose to work on during stand up meeting.

Our whole team including a manager sits in one room, we sit facing each other and talk to each other when ever need to (Face to Face communication). That also makes communication extremely easy and simple. In such an environment, team members learn from the indirect communication that takes place in the area without directly taking part in the discussion, Cockburn calls it Osmotic communication.

We also reference the board area; board area contains visual representations of the projects progress, risks and risk severity level.  Visual representations contained in this is area include agile boards (scrum board, release board, risk board and retrospective board) and information radiators (burn-down, burn up graphs, velocity, tasks dedicated, % completion of sprint and releases etc.) These resources ensure every member of the team is aware of the progress being made towards completion of tasks and overall project.

Our development cycles, called sprints, repeat every two weeks. Before every sprint we hold Sprint planning meetings which are attended by the whole team before every sprint.  A key sprint planning meeting attendee is Adam, the project owner.  He is responsible for creating requirements (user stories) and prioritizing them, based on his business knowledge and discussions he has with other team members. Adam is a good listener, and has immense business knowledge.    He is also available for any questions our team may have regarding the requirements.. Adam writes requirements and places in a repository called a backlog. Each requirement in the backlog is called a User Story. Adam also set the priority of the user stories in the backlog, that priority changes based on the discussion takes place between project owner and team during sprint planning sessions.

Our manager respects our opinion and encourages us when we disagree with him or someone else in the team, as long as we do it in respectful manner. In other words we are an empowered team. Also we select our work ourselves and collectively estimate the task and amount of time needed to complete those tasks, that liberty make us a self-driven team. During the planning meeting each user story is estimated and prioritized, in this process teams input plays a vital role. Adam changes the priority and estimation of the user stories in the backlog based on our team’s input.

I take help from Ken, Sara, Ali or Anita whenever needed or sometimes our manager asks us to help each other especially when we face a critical issue which could hinder the progress of whole project; a show stopper. If as a team we cannot solve an issue, we escalate it to Mark, the scrum master of our team. Mark is very affable and an approachable person, who keep us aware of the progress we are making. He is available and strives to remove any issues we have; technical or non-technical. He also makes sure that all the information radiators are up to date and meetings are being convened in time. He performs the role of facilitator and a leader at the same time, in other words he is a servant leader.

Adam, the project owner, is present in all the planning meetings including daily stand-up meetings which keep him aware of the progress of the sprint and release. He is subject matter expert and talks to the customer (Kevin) on the daily basis.  Occasionally, Kevin visits us and sits in our meetings. After every sprint team gives a demo of the product to Kevin and the team. That meeting and demo is called Sprint Review meeting. We welcome everyone to attend Sprint review meetings. It is a good time to get feedback on the product. Also Adam makes sure that the customers (Kevin and his team) understand what we are building and why we are building certain feature before others.

At the end of every sprint (after 2 weeks), we have another meeting called Sprint retrospective meeting within the team. Kevin (Customer Representative) usually does not attend sprint retrospective meeting.  In this particular meeting we discuss the processes we followed during the sprint. We point out what went really well and what did not go as good as we planned. Mark (scrum master) makes changes to the process followed during the sprint based on feedback given during the meeting. Changes to project processes include changes in communication, project velocity, and architecture design or any other practice or process. The number of tasks completed in a sprint by the team is called velocity of the sprint. It’s measured in ideal hours or Story Points.

We deliver or “release” the product to customer after every six sprints.   At release level we prefer to provide customer working software. Adam, the project owner, takes care of the User Stories at release level as well. He manages the release level backlog and selects user stories to be completed from Project backlog and moves them to release backlog. Release related planning is performed in release planning meetings. In summary, Adam manages three types of backlogs, project backlog, release backlog and sprint backlog.

Sometimes we still have a few stories left in the backlog at the end of the project. The reason is that we try to complete those requirements which add most value to the customer. Some of the features might not add that much value to the customer in the allocated project time so those requirements are not implemented in that project.

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

At the beginning of each iteration, team estimates how much effort is needed to complete a task/user story. Let’s suppose there are 5 tasks selected for a particular sprint and effort to complete those tasks is 38 Story points. Each task was estimated with following story points.

Task  1: 3
Task 2:  8
Task 3: 13
Task 4: 1
Task 5: 13

At completion of the sprint the numbers of tasks completed were different than estimated. Team could only manage to complete 4 tasks (1,3,4 and 5). So total story points completed during the sprint was 30 (3+13+1+13). Since completed story points is 30, which describe the work completed during a sprint. Hence velocity of the sprint is also 30.

Question is why velocity is so important?

The reasons that Sprint Velocity has given so much importance in agile methodology are following.

-          It measures the team’s work capacity.

-          It measures the team progress

-          It helps to estimate the time to complete the project

-          Variation of team velocity across different project might indicate some issue with the project

-          It helps to build tools using this information to monitor the progress of the project.

Here it is important to remember that every project has its own velocity. Velocity of one project should not be used to measure the progress of another one. In other words velocity cannot be used across the projects. The reason is that every project is different and might have different project members, circumstances, goals and dynamics. Applying velocity of one project to another one could provide the wrong estimate which ultimately can jeopardize the estimates and planning of the project.

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

The literal meaning of agile is to “Able to move quickly and easily”, which pretty much supports the idea of Agile development. Agile methodologies were introduced to quickly and collaboratively build quality software.

The Information technology is relatively new as compare to other fields, and when it came to following a methodology to complete an IT project the only examples to follow were from existing methodologies in manufacturing and construction industries. The Water fall development model is an example of methodologies which IT industry adopted from already established industries. The Water fall methodology is a sequential design process, the preset states of Water Fall methodology are planning, initiation, design, implementation and support.

Problem: As mentioned above Water Fall methodology is a sequential process in which each of the next phase gets started only after completion of its previous phase. This method works fine when all the requirements of the project are already well known and there is little or no chance of changing existing requirements. But for most of the IT projects requirements emerge with the time. Historically a big chunk of IT projects failed because software delivered on the requirement gathered in the beginning was not able to fulfill the needs of the end user. Sometimes end user don’t themselves know the requirements very well, they provide the requirement based on their understanding of the problem, but when product is completed and presented to them, even though it’s based on the requirement they had provided, they reject it because product does not solve the problem. Other times development team does not understand the requirement well, and create a product on wrong understanding.

Solution:

In response of high failure rate of IT projects experts came up with a different methodology which could solve the perceived problems of Water Fall methodology, they named it Agile methodology.

The goal is to develop the software based on customer’s continuous feedback, and to achieve that software is planned, designed, developed, tested and released incrementally.

The development time is divided into small (time-boxed) iterations. To improve the adaptability of the project Customer feed-back and Planning is incorporated in each iteration of the project. The continuous planning, continuous testing, continuous integration and continuous risk evaluation gives greater visibility and control on the progress of the project and consequently reduces the chances of project failure.

Agile software development emphasizes on adding value for the customer, and for that face to face communication, empowered teams, responding to change and working software are important agile practices and measures.

The basic values and vision of the agile methodology is described in Agile Manifesto and Agile principles which provide the basis to gauge the implementation of agile characteristic in your team.

Some of the most common agile methodologies are following.

• Extreme Programming
• Scrum
• Dynamic System Development Method (DSDM)
• Features Driven Development (FDD)
• Lean Software Development
• Kanban
• Crystal

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