Showing posts with label agile project management. Show all posts
Showing posts with label agile project management. 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 7 January 2016

Types Of Agile Coaches And What Do They Do?

Agile Coach

People may or may not have heard about the word “Scrum”, but for those who have, a question most commonly asked by them might be “What can Scrum do for me to improve my business?” or “How do I use Scrum to grow?” – A topic most discussed by CEOs, CTOs, project managers, and other senior level executives in a development company or organisation when they are faced with choices of adopting a framework to better their work processes and increase the investment returns for their organisation. It is important to understand that for a business new to Agile and Scrum a lot depends upon what type of Agile or Scrum coach it hires, and how successfully the coach can help the organisation to adopt Agile principles.



Agile can work wonders for you provided it is implemented in an effective way. Agile coaches ensure that business implement the framework in a proper manner. Therefore, a lot depends upon what type of Agile coach do you actually need? You may feel unsure about Agile adoption but serious enough to “give it a try” and see if it can benefit you. On the other hand, you may be aware about the benefits of using Agile but not certain how to start. It’s worth considering about the level of Agile coaching you actually need to get started.


What is an Agile coach?



What is an Agile coach? When the question is asked to different people you’re sure to get different types of answers depending upon whom you’ve asked. The perception of Agile coaching changes from individual to individual, and from company to company. Perhaps the main reason why this happens is because there are no standard definitions explaining Agile coaching, and people have the liberty to interpret the terminology in a manner they deem correct.

So, rather than trying to define exactly what an “Agile coach” is, it would be more worthwhile to comprehend what activities Agile coaching includes, and what does an Agile coach do when he/she is appointed by an organisation to facilitate or implement Scrum in their business processes. Coaching needs and activities vary from businesses to businesses based upon the type of product to be developed. However, in a typical organisation, there are three main areas where managements often decide Agile coaching is needed.

Agile Team Facilitator

An Agile facilitator may or may not possess a coaching certification from a reputed or known Scrum body. His/her primary role involves facilitating Scrum activities and mentoring Agile teams in achieving Scrum agility. The person usually engages with one or two Scrum teams – not more – and may lack experience or skill sets required for adopting and implementing Scrum to the fullest extent in the entire organisation.

Small organisations, or businesses having a limited Scrum budget but still interested in implementing Scrum may opt for Agile team facilitators to introduce Scrum in their organisations before deciding upon a concrete Scrum adoption plan. Usually, the objective of hiring an Agile team facilitator is to familiarise managements and development teams with the Scrum process and get an idea about how to go ahead with Scrum adoption, or, at times, to decide whether Scrum adoption is needed or not.

Agile Coach

An Agile coach can have one or more certifications from a well-known Scrum certification body. Unlike getting certified as a chartered account or a medical practitioner in a particular state or country, there are no formal or authorized “government recognized Scrum certification issuing authorities. Certification availed from a few Scrum entities like Scrum.Org, Scrum Alliance, Agile Coaching Institute, etc. carry value in the Scrum market, and employers generally search for coaches who have qualified or hold certifications from these type of institutes.

Agile coaches have a sound and relevant experience in at least one Agile discipline – Scrum, XP, or Kanban. They are certified Agile professionals who have achieved a high level of proficiency in their respective fields. They possess sufficient domain knowledge and coaching skills to facilitate and mentor the Scrum process in an organisation. An Agile coach trains the development team and the management in Agile principles and practices.  He/she contributes at both macro and micro levels, and in addition resolves all Scrum related issues. Often, Agile coaches promote and act as Scrum ambassadors in organisations which appoint them.

Businesses appoint Agile and Scrum coaches when they decide to go “all the way” with Scrum, and want to make sure they benefit from Scrum principles. Coaches are also consulted to discuss ways and means to develop better products, increase the ROI, and improve the current business processes.

Enterprise Agile Coach

An Enterprise Agile coach is a person who has achieved some additional skills such as advanced systems coaching, understanding work culture, training organisations in specialized business processes, implementing change management, and creating collaboration and leadership qualities amongst individuals which “regular” Agile coaches may not possess.

An Enterprise Agile coach may work at all levels in an organisation and help managements in using Agile as a strategic asset for generating consistent and reliable business value by improving current processes through Agile.