Showing posts with label Scrum Master. Show all posts
Showing posts with label Scrum Master. Show all posts

Monday 11 April 2016

Distributed Teams Challenges And Agile Advantages

Distributed Teams Challenges And Agile Advantages


Part 1 - Project management methods and Agile


With dynamically changing market scenarios dominating the outsourcing markets, it has become imperative to remain conversant with emergent technologies and use them for developing projects. New platforms and technologies have a lot to offer in terms of reduced development time and targeting a wider range of client-centric requirements, however, while reaping the benefits they offer, they also impose a few constraints regarding their applicability. Offshoring businesses can increase the productivity levels and generate higher profits but often face problems in finding technical teams familiar with the usage and implementation of new technologies. For most organisations, it is more profitable to find technical talent in other countries and outsource their projects depending upon the nature and scope of the project on hand. 

It is very important to manage projects in an effective manner to make them profitable. Several project management frameworks and methods aim to make project management easier and more effective. Some of the popular methods used in the past, and even now are:

  • Critical Path Method (CPM)
  • Critical Chain Project Management (CCPM)
  • PMI/PMBOK Method
  • Event Chain Methodology (ECM)
  • Extreme Project Management (XPM)
  • Adaptive Project Framework (APF)
  • Lean Development (LD)
  • Six Sigma/Lean Six Sigma
  • PRINCE2
  • Dynamic Systems Development Model (DSDM)
  • Feature Driven Development (FDD)
  • Rapid Application Development (RAD)
  • Systems Development Life Cycle (SDLC)
  • Waterfall (Traditional)



Each method proposes to make project management easy and more accurate. Often, it is difficult to choose which method one ought to adopt for developing a project since every management technique has its own pros and cons. While a particular organisation may offer a positive feedback regarding a method it is following, consultants might consider it a bad choice and speak against it. There are no postulates or rules which define a “successful” project. Also, there are no rules which can help in deciding whether a particular methodology is more effective as compared to the other. It is based more upon personal experience, understanding how a methodology works and what it has to offer, and how well it can be implemented. Perhaps, the most important aspect to understand is whatever methodology you choose, what is more important is how well you use it to your benefit to make your project successful.

Projects may vary in terms of their scope, size, complexity, and nature. However, regardless of that, offshore or distributed teams have to be properly coordinated and managed. Agile project management framework offers several options for managing remotely developed projects.

Agile frameworks
Scrum
Recommended for developing small to medium sized projects using a team of 7 to 12 cross-functional and multi-skilled individuals. The Scrum framework is characterized by its clearly defined events, artefacts, roles, and process which have to be followed by the entire team. The error correction and retrospection activities take precedence over documentation and delegation of authority. The client is actively involved in verifying the development carried out by the team. The Scrum team delivers the business value in the project through successful product increments developed through periodic cycles known as sprints.

Extreme Programming (XP)
Extreme Programming (XP) offers a practical approach to program development and focuses primarily upon the delivery of business results. It follows an incremental, start-with-something approach towards product development, and makes use of continued testing and revision processes. XP is generally recommended for short-term projects, and development teams typically follow code-test-analyse-design-integrate process. XP is known for “paired” programming i.e. two developers engaged with code development and testing simultaneously. One programmer creates the code while other tests it on the spot.

Kanban
Based upon the concept of Toyota production model, Kanban offers a pragmatic approach to development by matching the actual amount of work in progress to the development teams capacity in delivering it. The framework provides more flexibility in terms of planning options, quicker output, a clear focus pertaining what needs to be developed, and maintaining total transparency throughout the product development cycle.  

Scaled Agile Frameworks (SAFe)
Scaled Agile Framework (SAFe) is a structured and prescriptive method to help large organisations and enterprises to get started with adopting Agile. It is a popular and efficient Agile framework successfully used by many companies covering various industry verticals. It is specially recommended for large sized software based projects where teams can function interdependently.

Nexus
Nexus is an Agile framework focusing upon cross-team dependencies and team integration issues. It facilitates Agile implementation in complex and large scale projects. It functions as an exoskeleton and helps multiple Scrum teams to integrate and pursue a common goal of delivering valuable product increments through sprints. Each team delivers a certain business value to the client through each product increment cycle, and the teams achieve this by following Agile principles and process. Nexus is recommended for development teams consisting of over 100 individuals.


Part 2 – Agile for distributed teams


While executing your very first remote project, the most logical thing to do is to document the project vision and figure out how the team will deliver the project goals. Proper and effective communication is of paramount importance while explaining the goals and objectives to team members. It is a simple and straightforward process most of the times, but while working with distributed teams, the cultural differences and varying language proficiency levels may often create constraints and lead to miscommunication as well as confusion. This can be a common scenario in case of teams located in countries across different time zones and possess limited ability to communicate using a particular language. Individuals may find it difficult to understand and capture the exact project requirements and deliver code or functionality that does not fulfil end user requirements. Projects often fail because of these and other such technical and non-technical reasons.

Using Agile it may be possible to simplify these types of problems. Agile is not a silver bullet that can rectify all issues and problems faced during project execution. Agile is a framework, therefore It depends upon how well the team understands its principles and how effectively it implements them in the project. However, the framework is designed such that issues can be dealt with in a more proactive and effectual manner.

Part 3 – Dealing with issues using Agile


Businesses opt for remote or distributed teams mainly to segregate the development activity from the main organisation body by trans-locating the team and development activity to some other location for management or financial reasons. The team is directly employed by the organisation and each member is an employee. In case of offshoring, the entire project is outsourced to a development vendor who executes the project on behalf of the client, or develops it as a part of client contract. This discussion does not try to differentiate between whether the remote team is a part of parent organisation or it belongs to an outsourcing vendor. Some common issues faced while working with both types of teams are discussed and how those issues can be properly targeted using Agile. It is worthwhile to know that Agile is not the only project management platform to develop IT or software projects. Neither does it offer a guaranteed way of dealing with issues faced while working with or employing remote teams. However, the framework is uniquely designed, and is flexible enough, to deal with such issues in a more effective manner, and more easily.

Project vision and documentation
The project vision explains the goals and project deliverables. The primary aim of the team should be to deliver work supporting the vision so meaningful business value can be delivered to the client. Often, development teams put in efforts and deliver work, but when reviewed by the client, it is discovered that the features developed don’t exactly support what the client actually wants. This can be a very common scenario when teams are unclear about what the project aims to achieve and why it exists in the first place. Common reason why teams may fail to understand the vision could be language barriers (In case of distributed teams located in different countries and speaking different languages) or a lack of proper communication from the client’s or management’s side explaining the objectives.

Agile does not emphasize upon extensive documentation. In real life scenarios elaborate or extensive documentation often remains locked away in filing cabinets or resides on shelves for future references - teams rarely bother to read them thoroughly since they can be large in size and a lot of time is spent in reading and understanding them. The attitude of most development teams (Don’t mean to disrespect them in any way) is to get started with work so deadlines can be met. Teams are generally pressed for time so they don’t bother, or can’t afford to spend hours reading comprehensive documentation. Paperwork is greatly reduced in Agile, and if you choose to follow Agile, you need to create just enough documentation to get started with work. More importance is given to understanding client-centric requirements and delivering business value, rather than creating elaborate reports and documents. Moreover, one of the responsibilities of the product owner in Agile is to ensure that the team understands the deliverables and project vision properly before it starts to work. The PO also makes sure that the business value delivered from the sprints is useful and matches the project vision.

Maintaining quality standards
Quality and deadlines are two most important factors associated with, and affecting, the success levels of a project. Quality features fulfilling end user requirements have to be developed within the decided time so it can be properly marketed and business returns availed from it. In the IT market segment it is not just important to build quality software, but to release it in the correct manner at the correct time and at the correct place (targeted market audience i.e. the geographical boundaries within which end users are likely to buy your product. With online marketing these boundaries remain virtual but nevertheless play an important part in deciding the “target audience” when the project is planned and incepted). When outsourcing work to remote teams, the quality aspects could get compromised upon if a QA or testing process in set up as a part of development process. Fewer development teams actually bother to test the code for regression after it is developed unless it is a pre-decided activity and integrated with the development process.

The Agile manifesto states "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." It emphasis upon “early and continuous delivery of valuable software” i.e. useful and valuable product features should be developed and delivered to the client on regular basis. Agile focuses upon the delivery of “shippable” features. Each feature should be properly tested for errors and made bug free before its development can be considered as complete and deployable. Developers and programmers often double as testers to carry out the QA part during sprint cycles. Agile fails if “workable” features are not developed. Remote teams trained in Agile have to fulfil the test conditions stated in the acceptance criteria defined for each development task created in the product backlog (ideally).

The supervisor or project manager’s role
Every project needs a manager to oversee its execution and completion. It is important for the supervisor or the project manager to remain available to the team and resolve problems and issues as and when they occur. When teams are located on-premises it becomes easy to resolve technical problems since face-to-face interactions are possible and the manager is always available when you need him or her. That is not always the case with remote or distributed teams. Owing to time differences, the manager could be ending the day while the remote team would be just about to start with work. Teams may be required to wait for some time before problems are resolved, and this could delay work further. Deadlines and commitments may therefore not be met.  

The Scrum Master’s role is very clearly defined in Agile framework. The SM often plays a servant-leader role, and mentors and facilitates the Agile process. The SM ensures that he or she is always available to the team and resolves glitches whenever the team gets stuck. In Agile, the Scrum Master is a specific role played by a person, rather than a designation or responsibilities given to a single individual. The role can be played by anyone in the team. In case of distributed teams, a responsible team member can be taught to play the Proxy Scrum Master’s role and provided with quick-access channels to communicate with the actual SM or PO in case of urgent issues. The person also functions as a team representative and creates daily feedback reports which can be studied by the client, PO, and the SM as per their convenience.

Ownership and team empowerment
Traditional project management methods differentiate between senior and junior level individuals, and have a clear hierarchical structure defining authority levels and who reports to whom. Even today, most organisations still follow this traditional hierarchical model, and individuals belonging to different levels of authority remain concerned about their responsibilities and reporting status. Even though the model is organised, it takes a lot of time for issues to get resolved as the escalation process involves several individuals starting from the junior level to senior levels. Moreover, people have a tendency to “pass on” issues to senior levels personnel and let them decide what to do next. Technical staff and junior level employees may prefer not to get involved with decision making since they often become scapegoats to bureaucratic procedures. In case of distributed teams the scenario can become even worse because you don’t have to deal with just bureaucratic attitudes but the language and distance factor may further make the team even less accountable for the success or failure of the project.

Agile does not believe in shifting responsibilities or escalating issues. As per the model, teams are cross-functional and self-managing. Each team member often takes up additional tasks other than his or her particular skillset thereby reducing the total numbers of skilled members required in the team. There are no senior-subordinate levels – just three primary roles of product owner, scrum master, and the development team. Rather than assigning tasks, each team member voluntarily takes up work based upon his or experience and skills. One of the most important aspect about Agile is that the team has to “own” the project on behalf of the client. It means each person is responsible not just for the work done by him or her, but the overall contribution of all members at the team level is even more important. The entire team is accountable for the success or failure of the project – not just the product owner but each and every member of the team.

Moreover, the three roles of PO, SM, and the team are empowered in Agile to decide on their own what course of action to take to best fulfil their objectives. The development team is not required to follow orders or take permissions in deciding how a particular feature should be developed, and in what manner. It has to deliver work as decided in an event – the sprint planning meeting – held before each product incremental cycle known as a sprint starts.

Thursday 24 July 2014

Is Agile Scrum suitable For Software Development?

The scope of development in the software/IT field
People and individuals associated with software development and the IT field like to use the term “software development” to describe their particular field of work and professional involvement. The term “development” is very widely used to describe a host of activities catering to the IT field. It can range from developing code for applications and systems, to developing mobile applications for mobile operating systems such as Android, iOS, Symbian, Windows OS, etc. (visit http://en.wikipedia.org/wiki/Mobile_operating_system), “manufacturing” gaming software using scripting languages like Ruby, AGSScript, Lua, Marathon markup language, Ada, C++, C#, D, Lisp, Mercury, Pascal, Perl, Python, Scheme, JavaScript, Java, VBscript, EDL, etc., (visit http://en.wikipedia.org/wiki/List_of_programming_languages) carrying out web development using HTML, CSS, PHP, Joomla, DotNetNuke, Java, etc., and even developing entire operating systems for tablets and PCs  (visit http://en.wikipedia.org/wiki/List_of_operating_systems, to know more about operating systems). The fact is as on today, the terminology “software development” is extensively used to mention almost any type or activity associated with the programming and development of “computerizable” code of any type, in any way, or manner. When a particular methodology or framework is used to develop computerizable code and create software projects, it is important to ascertain whether the scope of development includes the specific activity you’re currently involved or associated with. Software development and projectmanagement frameworks such as Agile have the potential to develop successful IT related projects involving the vast majority of development platforms and operating systems.

While explaining Agile in a simple and straightforward manner, it can be best understood as a collection of project development methodologies and frameworks, of which any framework or methodology can be used in a successful manner to dynamically develop projects of almost any type and nature, including software development projects. The framework is based upon iterative and incremental development, in which self-organised and self-managing development teams understand, plan, and develop projects under the supervision of a project leader, and offer productivity in the form of short bursts of development cycles (iterative development) known as sprints. A unique feature of all Agile frameworks is that the development carried out by the team is “shippable” in nature i.e. the code developed during the product development cycle is independent, testable, verifiable,  documentable, and ready for deployment after it is stringently checked for any “manufacturing” defects.

A second, highly important feature of Agile development is that individuals “owning” the project are closely linked with the approval of development carried out by the team. A particular “code” or “piece” of functionality is checked for regression after it is developed, and subsequently presented to the stakeholders and project owners. They ascertain the development carried out, and clear it as “OK” for future integration into the actual product. This leads to a successful development of software projects, since the management is always aware about what functionality is currently being developed by the team, and up to what extent it satisfies the project objectives. If the project owners feel the productivity offered by the team is not up-to-the-mark, or fails to satisfies them in terms of business value (how much important the code or functionality is from the market point of view, and how much it is worth from the financial point of view) offered by the functionality, they can reject the entire functionality and instruct the project manager to redevelop the particular script or code, based upon a new set of inputs and requirements recommended by them. This ensures that the software project always “maintains” its business value at all times, even while the product is being currently developed.     

A third important feature of Agile framework is that all activities in the project are “time boxed”, and therefore, have to be completed within a predetermined time period. In an Agile project, each activity is time bound. All development related activities are “configured” to suit the unique project needs, and a duration “affixed” to them so they can be completed within a stipulated time. This ensures that the project does not “drag-on” and extend indefinitely. The development costs incurred while the project is being developed can be properly and “profitably” controlled, so that the project does not become “too” expensive and difficult to afford financially.

Agile framework differs drastically when compared to traditional linear or Waterfall methodology. In Agile, project development is carried out in short bursts of activities rather than in stages that have to be “completed” one after the other.

The main Agile features include:
·  Cross-functional development teams consisting of developers, programmers, testers, QA personnel, technical writers, system analysts, etc. all work together as a single composite team through collaborative efforts, offer and share ideas, and help each other during the development process.
·   Working in short, fast-paced development cycles, with focused objectives – Iterative development.
·  Shippable productivity at the end of iterative development cycles – Incremental development. The functionality keeps on “growing” through development cycles until the entire application, system, or product is developed.
·   Human communications and involvement takes precedence over management authority and delegation of work.
·   Total transparency and visibility of the team progress to project owners, stakeholders, and end users.
·    Feedback and suggestions help to self-correct and offer new ways and means to carry out quicker, more efficient, and reliable development.

An important feature of all Agile frameworks is that the frameworks are independent of the nature of project to be developed i.e. the framework is not dependent upon the platform or environment used to develop the particular software project. The architecture or design can vary, and could be anything. The important aspect is that an Agile framework has to be implemented in the project first, and its benefits availed subsequently. Please visit http://en.wikipedia.org/wiki/Agile_software_development.

Scrum, briefly, is a “light weight” Agile framework, used extensively for developing and delivering “workable” software products, very often, and on a consistent basis. The software products can range from the development of new web processes and systems, gaming solutions, plugins, mobile apps, ecommerce websites, corporate portals, development of WordPress themes, RAD (Rapid Application Development) projects, OOPs (Object Oriented Programming) projects, CAD/CAM drafting solutions, port programming and configuration utilities, web development and platform interfacing solutions, etc. Scrum adheres to all Agile principles and features discussed above since the framework is “inherited” from Agile itself.

Scrum offers a new, and a better way of managing software projects. There are many technical reasons why Scrum is popular and why many Fortune 500 companies prefer to use the framework for their project development purposes. While being introduced to Agile Scrum, a question that inadvertently comes to one’s mind is why is Scrum so popular? Why is there so much “hype” about Scrum? Does Scrum offer a magic formula, which can work wonders for your project and software development? Why should an organisation that has been following a particular development methodology, and feels comfortable doing so, should change over to Scrum? There is a separate article which deals entirely with why you should opt for Scrum. The point is, this article focus upon explaining Scrum to individuals who are new to the topic, and have absolutely no idea what the framework is all about, and what it can “do” for you. Efforts have been made to explain that Agile Scrum is applicable to almost any kind of software development, and possesses certain features which make the framework very popular as well as “powerful”.    


The actual Scrum process can prove to be difficult to understand, at first, for Scrum beginners. Even though Scrum implementation is not difficult, people need to understand and familiarize themselves about what is product increment, and how it actually occurs during the Scrum process. The second aspect is getting to know about Scrum events. The special meetings, known as “events” are important for monitoring the development activity, and analysing the reliability and effectiveness of the functionality developed by the team. They also help to solicit feedback from the team members as well as the project owners so that the business value of the project is not affected, and maintained at all times – even while the product is being developed. It is worthwhile to get an “overview” of the process first.  

Quickscrum- Scrum tool


1.    Project conception - An idea!
All projects, whether involving software development, or otherwise, start with an “idea”. Projects are developed out of needs. A project is planned to fulfil a particular requirement or achieve a certain objective. Moreover, each project results into “something” within a specific time frame – a project cannot extend indefinitely. It is important here to differentiate between a “project” and a “program”. Programs are generally long termed, and can even last for years, unlike projects which have a relatively short life span and last for a brief period, ranging from a couple of months to even a year.

Typically, a person, or a group of individuals realise it is worthwhile to put in efforts and resources, and develop “something” so that “another thing” can be easily fulfilled or availed. The “something” is the product, and the “another thing” is the solution that the project is supposed to provide. This stage of project development involves a lot of discussion and brain storming sessions, where the product is envisioned and “though over”.

Scrum does not figure during this stage. However, the vision seen by the project owners, can, or may, affect the manner in which Scrum is implemented in theproject, in the future. This is because the nature of product to be developed may require Scrum to be configured in a certain manner to obtain positive results from the project. 

2.    Project release – Getting started with the software project
Once the project is “thought about” the next logical step is to work out the nitty-gritty concerning the project dynamics – the objective of the project, the product definition, how the project should ideally deliver the product, in what manner, what should be the “strength” of the team, how many team members, etc.

Scrum development process does not come into the picture even during this stage. The documentation pertaining to the project is created and “everything” concerning the product to be developed is finalised – in black and white. Scrum does not advocate extensive documentation. You do not have to prepare detailed system flow diagrams and extensive design structures to get started with Scrum development. A basic idea will suffice, and you should only spend that much time and efforts which can get you “started” with the actual development activity. Just enough information and specifications to develop some of the most important product features.     

The project release is attended by the “Product Owner” – the person who functions as a project manager in the Scrum project, the Scrum Master who overseas that Scrum is properly implemented and followed by the team while the project is being developed, and the stakeholders or project owners who actually sponsor the project. 

3.    Creating the product backlog (Product Features List) – Defining the product features and functionality
The Scrum development process starts with the creation of a master list containing all features and functionality required to create the product in totality. In simple terms, the entire product, currently existing on paper as “imagined” by the stakeholders and project owners, is “broken down” into its constituent parts, consisting of individual features and functionality. The product is thoughtfully, and systematically, broken down such that each individual component can be individually developed, tested, and eventually integrated with other software components or functionality developed by the team over the days. Individually developed features and functionality can eventually “give birth” to a working product when integrated or assembled later on.

Each individual feature or list item is known as a “Product Backlog Item” or a “user story” in simple language. Therefore, the product backlog or the master list is fundamentally composed of product backlog items or user stories. The user story represents a product feature, and is individually developed by the team members during the development process – the daily sprints. Each story can be minutely defined. The description, acceptance criteria (Points which need to be “fulfilled” or satisfied before which the story can be considered as successfully developed), its importance in the project, and the manner in which it is supposed to be integrated into the final product, etc. are mentioned for each user story.

Once the feature list is created, it is arranged depending upon the importance of each user story in the product backlog. Important user stories are arranged in the “top” portion of the list, lesser important stories in the middle, and the least important features and functionality in the bottom portion.    

4.    Sprint planning meeting – Planning how to develop the product features
The product backlog functions as the main “backbone” of all development related activities in Scrum. Once it is “developed” by the product owner and the stakeholders, the actual development activity can start. A special meeting known as a “Sprint Planning” meeting is held to initiate the development activity. The meeting is attended by the entire development team, in addition to the product owner “PO” and the scrum master “SM”.

The meeting is held in two parts. In the first part, the product owner selects some of the most important user stories or product features from the top of the product backlog, and transfers them to a temporary list known as a “Sprint Backlog” for development purpose. During the meeting, the product owner takes the opportunity to explain each user story in details to the team members – how user stories should be ideally developed, and what activities the team should carry out so that each story can be marked as successfully completed.

During the second half of the meeting, the development team analyses the sprint backlog and distributes each story to individual team members. In practise, the team members unanimously decide as to who should take up which story depending upon their development skills and experience levels. Simple and easily developable items are given to less experienced or “fresher” while difficult, or more complex stories are taken up for development by more experienced and senior programmers or developers.         

5.    The daily sprints – Developing the product features
This is the main area of activity in Scrum. The entire product is developed in “bits” and “pieces” through the daily sprint cycles. A sprint cycle is nothing but a collection of working or “development” days during which the team members actually sit in front of a PC and develop the functionality or product features. The sprint cycle is time boxed and should not extend its deadline.

Each item included in the sprint backlog during the sprint planning meeting should be developed while the sprint is currently underway. A brief meeting known as a “Daily Scrum Meeting” is held for a maximum of 15 minutes each day before the team members start with their work. The purpose of the meeting is to get an idea regarding how much work has been completed by each member the day before, and what each member proposes to do “today”. If a team member is facing any issues or problems, it can be mentioned during the meeting, and the scrum master will ensure that the issue is quickly resolved.   

In Scrum, the daily sprints can typically last from 2 weeks up to a maximum of one month. The duration of the sprint is decided during the second stage - the project release - and it should not be extended under any circumstances - even if any of the user stories in the sprint backlog have not been developed, or whose development is incomplete.  

6.    Sprint review – Checking and verifying productivity (Is the development OK?)
Scrum emphasises upon the development of “shippable” functionality at the end of daily sprint cycle. Each user story developed during the daily sprint is checked by the product owner and verified for its reliability, acceptance levels, and whether it is “bug free”. In Scrum, it is very important to deliver error free features – each user story should be properly tested for any regression, and whether it satisfies the acceptance criteria linked with its development. 

Just after the daily sprint cycle ends, a meeting is immediately held to review the development carried out by the team. It is important to differentiate between the daily sprints and the sprint cycle. The daily sprint is the development activity carried out by the entire team on one particular working day. Many such “daily sprints” combine to form the “Daily Sprint Cycle”, also known as the “product incremental cycle” in Agile. The meeting is held at the end of the product incremental cycle – the daily sprint cycle. It is primarily attended by the product owner, the scrum master, and the team members. It is not mandatory for the stakeholders to attend this meeting. They can chose to attend it if they so desire.

The main objective of this event, or rather the meeting, is to check whether the features have been developed by the team as per the production plan, and if the functionality has any “manufacturing” defects. Each feature should be fully tested for any flaws by the team before presenting it in this meeting. The product owner verifies if the feature is error free and checks if it satisfies the acceptance criteria linked with it. It is a kind of “final” check carried out before presenting the development to the stakeholders and the project owners in the subsequent sprint retrospective meeting. During the meeting, the product owner instructs the team how it can improve its working and offer even better productivity by employing more efficient programming practices and standards.

7.    Sprint retrospective – Finalising product functionality and contemplating about further improvement
Agile Scrum advocates client participation. The client is a very important entity in Scrum, and has the final say as far as the development of product features is concerned. The Agile manifesto primarily stresses upon client participation and delivery of time bound product increments because these two aspects are very important for developing successful projects. A “satisfied” client often “comes back” to develop more projects since successful projects help the client to earn higher profit margins.

The retrospective provides an opportunity for the entire team to demonstrate its productivity in front of the stakeholders and clients. In addition to the product owner, scrum master, the development team, the meeting may also be attended by end users, technical staff personnel, vendors, distributors, and even other employees since the main purpose of the meeting is to avail feedback from individuals and entities closely linked with the market, and who have sound knowledge regarding what product features are likely to “score” in the market once the product is launched, and what can aid the product in “selling”.

The retrospective also offers a chance for the entire team as well as the client to reflect upon the development process, and discover what more could be done to make the product better. Discussions are carried out to ascertain the rate at which user stories are currently being developed by the team, and what new processes or methods need to be introduced to quicken the process.


Monday 21 July 2014

What Should The Perfect And Ideal Daily Stand-Up Scrum Meeting Consist Of As Per The Official Scrum Guide?

The daily stand-up scrum meetings play a vital role in ascertaining that the development activity is carried out in a sustained manner. The meetings are usually time boxed to 5–15 minutes and are held standing up to remind people to keep the meeting short and to-the-point. Stand-up scrum meetings also help to find potential pitfalls experienced during ongoing sprints. It is important to know how the daily meetings are carried out, and what they should ideally consist of. On the basis of official scrum guide specified by Jeff Sutherland and Ken Schwaber, the originators of scrum methodology, the article tries to explain in details about the daily scrum meetings.

·       Who should attend the meeting?
Everyone associated with the scrum project should attend the meeting. It is important for the scrum master and the team members to remain present, while the product owner and stakeholders too can remain present if they desire to do so.

·       What should be discussed during the meeting?
It is very important to remain focused and only discus about those topics which are directly related and associated with the sprint activity. The attendees should try not to wander off the main topic and discus about other trivia which are not pertaining to the scrum activity. In fact, the guide is specific about discussing topics which are directly connected to the sprint to be carried out during the particular day, even other topics dealing with the project, or project related issues should be avoided during the stand-up meetings. There are special provisions like the sprint retrospective meeting to discuss about such issues.The main topics to be included during the meeting should consist of:
-      What tasks were accomplished during the sprint carried out the day before?
-      Which tasks are to be developed today?
-      Did the particular team member face any problems or impediments during the sprint implementation? If so, what were they?
  
·       In what order should the discussions be carried out?
There is a lot of flexibility while deciding about the order in which the discussions can be carried out during the meeting. Team members can take turns in discussing about what they have achieved, and what they plan to do on the particular day. Alternatively, the scrum master may decide who should speak first and which team member should follow the discussion. A popular method is to take up discussions regarding important tasks first, followed by the order of priority. The order of discussion can vary from project to project, and from need to need. 

·       Where and when should the meetings be held?
The stand up meetings should be ideally held at the place of work, and in front of the task board. While they can be conducted almost everywhere, including conference rooms, holding the meetings in the actual place of work can help the team members to remain more focused and target oriented. The meetings should be held before the daily sprint is initiated.

·       How to sustain the energy levels during the meetings?
The stand up meetings are also commonly referred to as “huddles” by many people, simply because each team member stands very close to the next one during the meeting. The scene is much similar to the scrum used in rugby. The proximity often encourages the team members to become proactively involved in the discussion. The energy levels start rising up as each team member briefly, and professionally, discusses and outlines his or her activity for that particular day. The meeting is to be held in such a manner that the “atmosphere” becomes charged up with anticipation, and each member focuses upon the goals he or she plans to achieve during the sprint carried out that day.


                          Subscribe Free scrum tool from Quickscrum.com

Monday 9 June 2014

A Brief Overview about What Is Agile Scrum Framework and How It Can Help You in Developing Successful Projects

Scrum is a specialized type of project development framework. It is very popular owning to its fast and reliable product development cycle. It can be used for developing products, especially software based products, for which it is very extensively used nowadays. Many Fortune 500 companies currently use the scrum development methodology across the world owing to its popularity and effectiveness in delivering high quality products within the stipulated development time. The unique aspect about scrum framework is that it has an ability to “inspect” what is happening “in” and “around” a project in which it is implemented, and it can take corrective actions based upon the findings received as inputs from the process flow. The framework supports several activities known as “events” which can help to identify if anything wrong is happening with the project. When a malfunction or an erroneous activity is detected, the framework can take corrective steps to ensure that the “wrong” thing is corrected and rectified in a correct manner. The scrum framework is so structured that it can “self-detect” and “self-correct” itself through its events and specialized working.   

Typically, scrum is a development process in which teams collaborate and work together while creating the product. In scrum, development occurs in small stages known as “sprints.” Each small burst of development activity, or sprint, generally lasts from two weeks up to one month. At the end of each sprint, a special event known as the “sprint review” is held to find out how much development work has been carried out by the team, and how much of it is acceptable from the quality control point of view. Completed work is consolidated and accepted as “Done.” The unique aspect about scrum is that development is carried out in bits and pieces, rather than “as a whole” and “all together.” Each piece or developmental unit is developed individually and tested for flaws. These pieces are subsequently integrated to form the complete product. Rather than controlling the project as a whole, scrum ventures to control the development of individual pieces or product functionality. The developmental units, or “pieces” are referred to as “user stories” in scrum. Once all the user stories are developed and integrated, a total, comprehensive, and “shippable” product is automatically developed. This product is tested at a micro level with regards its functioning and reliability. This is one of the major reasons why many development companies and organizations prefer to use scrum framework in their production processes.

There are many reasons why people choose scrum for their project development activity.

Reduces technical debt and eliminates regression
At any given instance of time, the team develops a small portion, or a thin slice, of the actual product. This portion is further divided into even smaller developable units that are individually developed by the team members. Once a particular “unit” is completely developed, it is tested for its completeness and usability. It provides an opportunity for the team to test individual product components at a micro level. Tackling problems at a root level leads to zero regression and highly reduced technical debt in the future. This is how scrum controls technical debt related problems before and after product deployment.

Maintain the business value of the project at all times
After a small portion of the product is developed and tested for its reliability, it is demonstrated or showcased to the project owners and stakeholder – people who actually own the project. Their feedback is availed regarding the functionality which has been developed by the scrum team. Once they Okay the development, the portion is accepted as “Done.” If the owners are not satisfied, the development is transferred to a master list from which it can be taken up again for development purposes. Thus, only useful and effective developmental activity is carried out in the framework. The system is so structured that it can reject substandard work. Moreover, each developmental unit can be correlated with its “worth” in the market i.e. when a particular functionality is developed by the team how much it will be worth in the market when integrated in the actual product. This ensures that only meaningful development having a certain financial significance is “churned” out by implementing the scrum framework. Each product unit developed has a certain business value attached to it. This ascertains that the business value of the entire project is maintained at all times.

Collaborative features which can streamline productivity and increase it
One of the biggest advantage of scrum framework is that it solicits feedback from the team members and the project owners at all times. Each user story, or the development unit, is precisely stated in a master list known as a “product backlog.” This master list contains each and every “item,” or a developmental unit needed to develop the product in totality. Each item in the list is minutely defined. The specifications of the functionality to be developed, its description, explanation, and what benchmarks it needs to satisfy to be accepted as “Done” are clearly stated in it. This makes development much easier for the team members since the criteria is clearly laid down and the team knows exactly what functionality to develop, in what manner, and what kind of outputs are expected after developing the product item. The feedback system further helps the team to collaborate and discuss the technical aspects regarding the development activity. This helps to streamline the production process. The team members can help each other during the product development phase. All senior as well as junior team members support the collaborative nature. When the team faces any problems or impediments, a project leader known as a “product owner” tries to provide a solution for the problem – if necessary by interacting with the stakeholders and other technically sound individuals. The collaboration process helps the team to function in a highly productive manner.

Adapting to changing market conditions and developing successful projects
A major advantage with scrum is that if follows the “inspect” and “adapt” principles. The framework possesses inherent features which facilitates inspection and retrospection. The development of a product can take a certain time. If the product definition is complex or complicated, it may take a longer time – even months – to develop the product in totality. Many a times while the product is being developed, the market conditions may change over time and render some of the functionality associated with the product as redundant. As a result, a product when launched in the market after months of development may lose its business value and find it difficult to compete with other similar products, because other products may have gained a “stronghold” and strengthened their position owing to their prior release. Companies more than often suffer substantial financial losses when this happens. Scrum helps to avoid this. The stakeholders are very closely associated with the project during its developmental phase. They have the opportunity to decide which of the product functionalities carry high business values, and which functionalities can help the product to succeed financially in the market. During the product development cycle, the stakeholders can introduce new functionality, remove existing functionality, and even suggest changes in existing functionality so that the entire project is able to maintain its business value at all times – during its inception, development, and the subsequent release. Projects developed using scrum framework are profitable and help to earn higher ROI for the stakeholders.

These are only a couple of reasons why organisations across the world opt for scrum framework. The are many other factors which entice “C” level executives and mega corporate to choose scrum as their development framework, however, it would take a much more detailed discussion and a personal coaching to truly understand the vastness and depth offered by scrum. The framework is so agile that it can adapt to almost every type of project, however large and complicated it may be, and still deliver it successfully and nicely “wrapped up” for its final deployment. It is worth knowing something more about scrum to avail a better picture about how it functions.


The scrum process starts with an activity known as a “Release Planning.” When a project is planned, or decided, the stakeholders appoint a person to execute and look after the entire project. The person is known as a “Product Owner.” The person represents the stakeholders and their interest in the project. The product owner (or the “PO” in short) starts planning about what needs to be done to execute the project in a systematic and planned manner. He or she starts preparing the documentation which includes various aspects concerning the project, such as the feasibility aspect, market dynamics, product specifications, etc. The report is presented to the stakeholders, which helps them to decide further as to what they actually need and desire out of the project. The report helps the stakeholders to understand the reality about how the product proposed by them is likely to perform in the market based upon what they have envisioned. This process is generally known as a “release planning.” The PO then proceeds with the project based on their feedback and suggestions. The PO starts preparing a master list known as a “product backlog” in scrum. The list contains individual items, known as “product backlog items” or “user stories,” which are required to develop the entire product. So looking at it conversely, the entire project is bifurcated into smaller individually developable parts known as user stories, which actually form the product backlog. The PO carefully writes down these stories. He or she can also invite and take help from the team members while drafting the stories. The stories include specifications about the functionality to be developed by the team. Once the backlog is created, the PO analyses which of the stories are most important from the functionality point of view, and which of them carry high business values. Important stories are located in the top of the list so they can be developed first. Generally, the product backlog is processed from top to bottom, so important stories can be developed first.

The sprint planning meeting
The actual development activity starts with a scrum event known as “Sprint Planning.” A meeting is conducted to support this event. The sprint planning meeting is actually held in two parts. During the first part of the meeting, the PO takes some of the important user stories from the top of the product backlog and transfers them to a temporary list known as a “Sprint Backlog.” This list is important to the team members since it contains the product items which are to be developed in the subsequent days. During the meeting, the PO explains what needs to be developed, in exactly what manner, and what conditions need to be satisfied to have the user stories accepted as successfully completed. The conditions are known as “Acceptance Criteria.” The team avails an opportunity to ask questions and seek clarifications regarding the subtle development points which are not clear. In the second half of the meeting, the team analyses the sprint backlog which contains items to be developed in the coming days. The members split up the stories into small developable sub-units known as “tasks.” Once the tasks are distributed amongst the team members, the actual development process starts.     

The daily scrum or “stand up” meetings
In scrum, the actual product development is carried out in short bursts of activities known as sprints. A sprint generally lasts for two weeks up to a maximum of one month. The PO and the team collectively decide the actual duration of the sprint keeping in mind various factors such as the level of complexity, size of the projects, the product release date, etc. Once a sprint duration is decided, it is “fixed” and cannot be changed later on. Each day, before the developers start with their day, a brief meeting is held to initiate the daily sprint activity. This meeting is called the “stand up” meeting or the “daily scrum.” The reason why the word “scrum” is used to describe the meeting is that scrum team members huddle together just as rugby players do on the field when they start with their “rugger” scrum. The purpose of holding the meeting is to make the team accountable for the work it has carried out the day before, and discuss what work is to be carried out on that particular day. The daily scrum meetings provide an opportunity for the team to briefly discuss and provide feedback regarding how many tasks have been completed by them. If any team member faces an issue or a problem, it is discussed in the meeting and a solution is availed to resolve the impediment. The meeting is very brief and time boxed. It should not extend for more than 15 minutes. The meeting is held on each day of the sprint to “start the day.”

The sprint review meeting
The development work is carried out by the team in the daily sprints. At the end of two weeks (sprint duration), when the sprint is completed and user stories have been developed by the team, the PO checks the development and verifies whether the stories have been developed properly, and whether the acceptance criteria is satisfied correctly. In scrum, it is very important to develop “shippable” functionality i.e. the tasks developed by the team should be bug free, documented, tested, and acceptable by the stakeholders. Many cross-functional scrum teams employ testers and QC personnel whose sole task is to check whether the user stories developed by the team fulfil the acceptance criteria. If this is not possible, the PO evaluates the tasks and verifies whether they are acceptable. This process is carried out in a scrum event known as the sprint review meeting. It is held just after a sprint is completed. The main purpose of this meeting is to verify the development work, and if some of the tasks do not fulfil the acceptance criteria, they are “rejected” and transferred back to the product backlog from where the user stories can be taken up again for development. Thus, regression is “checked” and controlled through the scrum process.

The sprint retrospective meeting
The scrum process invites feedback from the stakeholders. People who own the project get a chance to check the productivity and provide feedback while the product is being developed. In scrum, the development and productivity of the team is directly and indirectly controlled by the feedback received from the stakeholders, end users, and the technical teams. If productivity is carried out by the team in a proper and acceptable manner, the user stories and tasks developed will have a certain business value attached with the functionality linked with the tasks. A scrum event known as the “sprint retrospective” provides an opportunity for the stakeholders to ascertain the work carried out by the team. The sprint retrospective is held immediately after the sprint review meeting. The main difference between the review and the retrospective is that in the review the PO verifies the tasks and checks for acceptance criteria, while in the retrospective the stakeholders check the user stories and tasks for the business value availed in the ongoing project. While the PO is primarily concerned with the technical aspects and represents the stakeholders’ interests, in the retrospective the stakeholders see for themselves how important the user stories are from the business point of view. The retrospective also offers an opportunity to educate the team and offer valuable suggestions to enhance the project vision and make certain aspects clear to the development team as to what the team should ideally focus upon.     

Scrum Roles

Product Owner
He or she is the main person who executes the scrum project. The person is primarily responsible for the success or failure of the scrum project, and, in addition, represents the stakeholders’ interests while scrum framework is being implemented in the project. There are many responsibilities of the product owner, and it would take a lengthy discussion to explain all of them.

Just as a supervisor overseas the production process in a manufacturing unit, similarly a scrum master overseas that scrum framework is properly implemented at all times while the project is underway. The scrum master does not actively participates in the development work carried out by the team, but rather “keeps an eye” on how things are going on and whether the team faces any impediments while work is underway. The role of a scrum master is a passive one, but important. The PO generally does not have enough time to oversee the entire project operation since he or she is actively busy with the “macro” aspects concerning the project. The scrum master, on the other hand, concentrates on the “micro” aspects of the project and remains very close to the team, and helps them directly and indirectly by removing the obstacles whenever the team faces them in any way or manner.   

Development Team
It is the main “functional” unit of the scrum team. The product is actually developed by the development team in scrum. Ideally, the development team is cross-functional i.e. each team member possesses multiple and varied technical expertise. The team members collaborate and share ideas while working. 

Scrum Artefacts Or Objects

In scrum, the entire product is broken down into smaller, individually developable units known as user stories. User stories, also known as product backlog items or PBIs, are developed by the team during the daily sprints depending upon their importance and business values. They form the base of the entire product. Individual user stories are later integrated to form the complete product. Typically, user stories include a title description, an explanation describing the functionality to be developed in the story, some important points that clarify the development activity, and the acceptance criteria. User stories also include a numeric value which indicates how important the particular story is from the business value point of view. This value is the “story point.”

Product Backlog
It is the master list which includes the product backlog items, or the individual product components, which constitute the actual product developed in the scrum project. Periodically, the product backlog is checked and verified for any missing parameters in the user stories (whether any of the product backlog item is inappropriately described or lacks proper acceptance criteria) and the business value associated with the user stories. With time, the business values of the user stories change with changing market conditions. The stakeholders provide feedback regarding the changes in the business values of the user stories, and the product owner updates the user stories with the new business value as provided by the stakeholders. This process of updating the product backlog is known as “backlog grooming” or “backlog refinement” in scrum.

Sprint Backlog
During the daily sprint, the user stories prevailing in the entire product backlog are not taken up for development. Rather a small “chunk” or portion of the product backlog is taken up for development during the daily sprints. This small portion of the product backlog is temporarily stored in a list known as the sprint backlog. The PO creates the sprint backlog during the sprint planning meeting. 

Burn down Chart
Each user story in scrum is associated with a certain business value by using story points (a numeric value indicating the importance and the business value of the user story). The correlation of the user stories with story points is important in scrum since it becomes possible to find the “rate” at which the development team is “performing.” It becomes easy to create an estimate and determine the “speed” at which the team is currently developing the user stories. This estimation can be plotted in a chart, or a graph, known as a “burn down chart” in scrum. 


 The QuickScrum project management tool developed by Bharti Softtech is a powerful, easy to use, and versatile web based scrum tool application centred upon Scrum framework. The tool helps to incorporate scrum methodology into project development, and offers a dynamic scrum management environment. It includes powerful features such as easy to use drag-and-drop features, dynamic update of each product backlog item, its status, breakdown of backlog items into individual tasks, preview of backlog items created in earlier sprints, and much more. It is ideally recommended for organisations, project managers, and scrum teams desiring to implement scrum framework in their projects. The tool helps to save time, reduce operational overheads, and increase the development team’s productivity, which can lead to higher profits and increased ROIs.Source:- http://blog.quickscrum.com/post/2014/06/06/A-Brief-Overview-about-What-Is-Agile-Scrum-Framework-and-How-It-Can-Help-You-in-Developing-Successful-Projects.aspx


     Please visit http://www.quickscrum.com for additional details.


Wednesday 23 April 2014

Seven Unique Ways To Breath In New Life In Your Sprint Retrospectives

Sprint retrospectives are an important part of scrum methodology. For Agile practitioners, retrospectives hold a special significance, and offer an insight into the self-learning capabilities supported by scrum.

The primary objectives of a sprint retrospective meeting are:
·       Display the user stories to the stakeholders, which have been developed by the team during the daily sprints  
·       Have the user stories accepted by the investors as “shippable”
·       Discuss and review the entire sprint, and analyze it to find how the sprinting process can be improved upon
·       Find what lessons can be learnt from the sprint, and how the team can benefit from prior findings and experiences
 
One of the issues faced by the scrum team is the team members end up discussing the same issues and problems in most of the retrospective meetings. The team feels it is discussing the same topics again-and-again, and therefore it is redundant to hold retrospectives. In all aspects, the retrospectives seem to be going “stale” and the team might be just holding it because scrum advocates it. The learning and self correction process stops in such cases, and the retrospective loses its importance and functionality.

So how can you pump in new life in the retrospectives? A few pointers may help you improve your meetings.

1. Rotating the leadership
Instead of the scrum master facilitating the meeting, invite the team members to temporarily assume the role of a scrum master and conduct the meeting. Each member takes turns and facilitates the meeting in his or her own particular way and manner. The members can be asked to experiment with newer adaptations and ways of holding the meeting.

2. Changing the questions
The two standard questions most commonly asked during the meeting are:
1.     What did we do well this time?
2.     What can be possibly improved upon in the next sprint?
Instead, try asking the question:
·       What actually happened during the sprints, and how did it occur?
Individuals tend to look at things from their own perspectives, and at times, they might fail to comprehend the true situation if they are forced to look at issues from a different point of view which they are not familiar with. Asking questions which they find easy to answer can go a long way in making the retrospective more interesting and useful.

3. Varying the process
Each scrum team has its own method of conducting the meeting. While some teams prefer group discussions during the retrospectives, a few of the teams follow the traditional pattern of having one member demonstrate his or her work to the stakeholders. Whichever process you follow, try to change it by including variations into the meeting pattern. A recommended method is to use histograms indicating member satisfaction levels. The survey can be conducted anonymously and the findings presented to the entire team. Suggestions can be availed from the team members as to what new aspects ought to be incorporated to make the meeting interesting. 

4. Thinking about unique perspectives
Individuals and people who are not directly connected with the scrum project, but are still attached to the project somehow can be invited to attend the meeting. Vendors and system deployment personnel have different insights to offer since they are directly connected with the market and have a “working knowledge” about consumer psychology and requirements. Their participation can help the scrum team to avail a broader perspective regarding how the development of user stories should be ideally carried out.

5. Changing the focus
Every team has a certain focal point, which it concentrates upon while developing the project. Switching the focus can also prompt the team to come up with new ideas about how the scrum process can be improved upon. If the team is concentrating too much upon the engineering practices, the focus could be changed to collaborative working and solving technical issues by sharing out the problems.Read more on http://blog.quickscrum.com/post/2014/04/09/Seven-Unique-Ways-To-Breath-In-New-Life-In-Your-Sprint-Retrospectives.aspx


         "Please visit http://www.quickscrum.com to Free download the Quickscrum tool"