Agile Vs Scrum

A  Scrum Master works with “A” team. An Agile Coach works with ALL teams, AND executives AND other teams/groups. A Scrum Master ensures that the team is following the Scrum process, doing the ceremonies and behaving the right way.

The Scrum Master’s Role: 

A SM will usually focus on a single team or a couple of teams at most. Anymore and they are highly unlikely to be very effective.


 Their primary focus will be internal by ensuring the team: 


§ Communicates well to each other and stakeholders


§ Collaborates with their Product Owner to deliver work that holds business value


§ Understands and embodies the Agile values and principles set out in the Agile Manifesto 


They will use many of the techniques associated with Agile Coaching, for example: 


§ Training courses to fill in existing skills gaps, e.g. user story writing


§ Facilitating ceremonies such as the retrospectives


§ Mentoring individuals in specific Agile practices as needed

And possibly: 

§ Professional coaching; that is using techniques to guide the individual to uncover answers to their own challenges, rather than imparting knowledge. 


As the SM and the team mature, the SM will understand there are external factors that impact the team. The SM will begin focusing more of their time on these external factors. They become agents of change for their organisations again using some of the skills that would be associated with Agile Coaching. Their focus will still be the team but they will look to how managers and other teams affect the work the team does. This activity could include but is not limited to: 


§ Facilitating/Participating in a Scrum of Scrums ceremony to understand the landscape of the wider department


§ Training other teams in order to build up common skills/knowledge


§ Identifying behaviours in other teams which impact their team, working with other SMs to resolve this 


The Agile Coach’s Role:


 An Agile Coach(*) will work with a number of teams either directly or through the team’s’ management. It is unlikely they will be able to develop the same level of personal relationships with the teams like an SM can, because their scope is set across a much wider area. Instead they will work with the managers and Scrum Masters to increase the overall agility of a number of teams. 

For example: 


An Agile Coach will either be assigned to a set of teams or will spend time observing how work is done within the wider group. Then they will use some of the same skills as a Scrum Master to help these teams improve, for example training. But they will also exhibit other skills that go beyond those of a Scrum Master. For example, an Agile Coach could leverage their advanced skill set, experience and knowledge by sharing concepts such as systems thinking to uncover feature teams. Alternatively a coach could work with a group of managers and HR to design a new reward structure. The skills needed for these organisation/management level challenges are very different to those of a SM.The Agile Coaching Competency framework from the Agile Coaching Institute sums this up well in that the two roles are largely defined by the level of scope and influence. 


An Agile Coach will have a deep knowledge of the practicalities in the agile/lean space, which will be wider and deeper than that of a SM. Additionally, they will have a range of skills in Teaching, Mentoring, Facilitation & Professional Coaching, and their own delivery style which will be a blend of all of these techniques. Finally a coach will be a specialist in one of three domains, Technical, Business or Transformation. Where the Agile Coach specialises will be down to their experience and background. 


For instance an Agile Coach focussing on the technical domain will have deep experience with a range of programming languages, automation, testing, delivery pipelines etc. Whereas an Agile Coach specialising in the Transformation domain will be an expert in systems thinking, organisational design and concepts like theory of constraints and operating model design. 


A SM will have more limited knowledge in these areas due to the scope of their work. For example, a SM could know a lot of techniques required in the Business domain (ie. Product focus) at a team level e.g., helping teams learn how to split user stories or story prioritisation. However, they won’t have the skills to mentor higher level managers in building an agile portfolio or cover the training required for agile budgeting. 

Two similar but distinct roles, complementing each other 

Hopefully from the brief summary above you can see how a SM and Agile Coaches roles will differ. But it is important to remember that these two roles should not negate each other. Just because an organisation has hired an Agile Coach does not mean they would not benefit from dedicated SMs, and vice versa. In fact the most successful applications of agile practices will use a blend of SMs and Agile Coaches in order to bring onboard the range of skills that are needed. The roles then take on a synchronised nature, where the SMs and coaches collaborate in order to further the agile vision of that organisation. 

Top 3 cloud services

In a multi-cloud world, organizations may use different cloud providers for multiple capabilities concurrently. Most of the cloud service providers (CSP) out there offer high-quality services, with excellent availability, high security, good performance, and customer support. But the market is dominated by a top three—Amazon Web Services, Google Cloud, and Microsoft Azure. While these three cloud providers collectively dominate this sphere, their approach to cloud computing is strongly dictated by their background.

Compute, storage, databases and networking


                       For compute, AWS’ main offering is its EC2 instances, which can be tailored with a large number of options. It also provides related services such as Elastic Beanstalk for app deployment, the EC2 Container service, AWS Lambda and Autoscaling.Meanwhile, Azure's compute offering is centred around its Virtual Machines (VMs), with other tools such as Cloud Services and Resource Manager to help deploy applications on the cloud, and its Azure Autoscaling service.

Google's scalable Compute Engine delivers VMs in Google's data centres. They are quick to boot, come with persistent disk storage, promise consistent performance and are highly customisable depending on the needs of the customer.All three cloud providers support relational databases - that's Azure SQL Database, Amazon Relational Database Service, Redshift and Google Cloud SQL) - as well as NoSQL databases with Azure DocumentDB, Amazon DynamoDB and Google Bigtable

AWS storage includes its Simple Storage (S3), Elastic Block Storage (EBS), Elastic File System (EFS), Import/Export large volume data transfer service, Glacier archive backup and Storage Gateway, which integrates with on-premise environments.Microsoft’s offerings include its core Azure Storage service, Azure Blob block storage, as well as Table, Queue and File storage. It also offers Site Recovery, Import Export and Azure Backup.All three typically offer excellent networking capabilities with automated server load balancing and connectivity to on-premise systems.

Pricing

                    Pricing can be a huge attraction for those considering a move to the cloud, and with good reason: there has been a continued downward trend on prices for some time now as the big providers compete. However, making a clear comparison can be tough as all three offer slightly different pricing models, discounts and make frequent price cuts.

All vendors offer free introductory tiers, allowing customers to try their services before they buy, and typically offer credits to attract innovative startups onto their platforms as well as 'always free' tiers with strict usage limits.

For example, Google offers free usage up to 1GB of Google Cloud Datastore capacity, 28 instance hours per day for Google App Engine, one micro sentence per month for Google Compute Engine, 5 GB-months of Google Cloud Storage (regional only), 2 million Cloud Functions per month, 50GB of logs with Stackdriver for monitoring, as well as limited access to products like: Google Cloud Natural Language, Cloud Vision API, Kubernetes Engine and more.

Customers

             A high-profile user base may not be the main reason for choosing your cloud provider, but it can help more cautious organisations understand how the public cloud is benefiting others in their sector.This is clearly a strong point of AWS. It has increasingly taken on large customer deals. For example, although the US Central Intelligence Agency eventually signed a contract with IBM, it awarded AWS a contract to build its private cloud in a one-off deal in 2013, which could be seen as a symbolic moment for potential buyers.

A longstanding AWS customer is Netflix, which eventually decided to shut all of its data centres in a final move to the cloud in 2016. But aside from web pioneers, AWS has been truly successful in convincing more traditional businesses to move to the cloud.UK bank HSBC has opted for Google Cloud for its analytics and machine learning capabilities. However, HSBC is taking a clear multi-cloud approach, partnering with all three providers for different workloads.

Agile Road map - 7 stages

"Breakthrough products don’t come from thinking small. They don’t come from the fear of losing ground, either. They come from thinking big and responding to change better than everyone else. "

                        -Janna Bastow, Co-Founder of Mind the Product and ProdPad.

An agile product roadmap revolves around desired goals and outcomes, instead of features or timelines.With an agile roadmap, you can communicate both your big picture narrative—that pie-in-the-sky vision—and the series of steps you anticipate will help you

meet that vision over time. The steps matter, but they also don’t.

Technology will change, new and unexpected markets will open up, business will boom or suddenly drop, and all of these changes will affect what you’re able to build both in the short- and long-term. You can’t exactly know what you’re going to build ahead of time, but you can plan for how you’re going to respond to change in order to keep on track with your innovative vision.

• Stage 1, the product owner identifies the product vision. The product vision is a definition of what your product is, how it will support your company or organization’s strategy, and who will use the product. On longer projects, revisit the product vision atleast once a year.
• Stage 2, the product owner creates a product roadmap. The product roadmap is a high-level view of the product requirements,with a loose time frame for when you will develop those requirements. Identifying product requirements and then prioritizing and roughly estimating the effort for those requirements are a large part of creating your product roadmap. On longer projects, revisethe product roadmap at least twice a year.
• Stage 3, the product owner creates a release plan. The release plan identifies a high-level timetable for the release of working software. An agile project will have many releases, with the highest-priority features launching first. A typical release includes three-to-five sprints. Create a release plan at the beginning of each release.
• Stage 4, the product owner, the master, and the development team plan sprints, also called iterations, and start creating the product within those sprints. Sprint planning sessions take place at the start of each sprint, where the scrum team determines what requirements will be in the upcoming iteration.
• Stage 5, during each sprint, the development team has daily meetings. In the daily meeting, you spend no more than 15 minutes and discuss what you completed yesterday, what you will work on today, and any roadblocks you have.
• Stage 6, the team holds a sprint review. In the sprint review, at the end of every sprint, you demonstrate the working product created during the sprint to the product stakeholders.
• Stage 7, the team holds a sprint retrospective. The sprint retrospective is a meeting where the team discusses how the sprint went and plans for improvements in the next sprint. Like the sprint review, you have a sprint retrospective at the end of every sprint.

In brief,An agile road-map helps you communicate your priorities in clear “what problems are we trying to solve?” terms for everyone you work with.You don’t need to know exactly what you’re working on ahead of time. It’s fine to have a fuzzy idea of what’s way out in the future and prioritize what’s coming up now.

According to the 2018 State of Agile Report, 75% of respondents adopted an agile approach within the last year, with the aim of accelerating software delivery. The results? Over 60% cited that Agile improved their time to market, project visibility, team productivity and management of changing priorities.

Warerfall Vs Agile

Technologies are constantly changing and so do management methodologies. What worked yesterday might not work today, and vice versa. How can you then be confident that your project is managed correctly?

We are experiencing a real boost of project management approaches and methodologies. In the IT world, the most widespread and popular one is, of course, Agile. However, there is no “one size fits all” when it comes to software development, that’s why it is crucial to know your project scope first.

We recommend using Waterfall if: 

·           You don’t expect changes in scope and you’re working with fixed-price contracts

·           The project is very simple or you’ve done it many times before

·           Requirements are very well known and fixed

·           Customers know exactly what they want in advance

·           You’re working with orderly and predictable projects

And you should use Agile if:

·           The final product isn’t clearly defined

·           The clients/stakeholders need the ability to modify the scope

·           You anticipate any kind of changes during the project

·           Rapid deployment is the goal

When deciding between Agile versus Waterfall, it can all boil down to this: if you anticipate or expect any changes throughout the project, go with Agile. If you know the project is fixed, unchanging, and predictable, Waterfall may be a better choice.

Drawback Waterfall

·       One area which almost always falls short is the effectiveness of requirements. Gathering and documenting requirements in a way that is meaningful to a customer is often the most difficult part of software development, in my opinion. Customers are sometimes intimidated by details, and specific details, provided early in the project, are required with this approach. In addition, customers are not always able to visualize an application from a requirements document. Wireframes and mockups can help, but there’s no question that most end users have some difficulty putting these elements together with written requirements to arrive at a good picture of what they will be getting.

·       Another potential drawback of pure Waterfall development is the possibility that the customer will be dissatisfied with their delivered software product. As all deliverables are based upon documented requirements, a customer may not see what will be delivered until it’s almost finished. By that time, changes can be difficult (and costly) to implement.

Drawback - Agile

·       The very high degree of customer involvement, while great for the project, may present problems for some customers who simply may not have the time or interest for this type of participation.

·       Because Agile focuses on time-boxed delivery and frequent reprioritization, it’s possible that some items set for delivery will not be completed within the allotted timeframe. Additional sprints (beyond those initially planned) may be needed, adding to the project cost. In addition, customer involvement often leads to additional features requested throughout the project. Again, this can add to the overall time and cost of the implementation.

·       The close working relationships in an Agile project are easiest to manage when the team members are located in the same physical space, which is not always possible. However, there are a variety of ways to handle this issue, such as webcams, collaboration tools, etc.

·       The iterative nature of Agile development may lead to a frequent refactoring if the full scope of the system is not considered in the intial architecture and design. Without this refactoring, the system can suffer from a reduction in overall quality. This becomes more pronounced in larger-scale implementations, or with systems that include a high level of integration.

How to Estimate Budgets in Agile?

                                      

Estimating the cost before the project even starts can always be challenging, regardless of which project methodology you use. However, in an Agile project, you can tie the amount of time the project will take with its total cost.

First, create a burndown chart and use the burndown rate to estimate how many sprints will be in your project and when the project will end. Then, calculate how much the team will cost based on their hourly rates. Multiply each person’s rate by the number of working hours per week, then multiply that by the number of weeks in a sprint. Once you estimate the initial budget for your team, you can add any other costs, like technology, travel, or equipment.

You could also break down each user story into tasks. Once you have an idea of how many hours it will take to complete each task, you can estimate the project budget.

And lastly, you could use planning poker to estimate the effort required for development goals. Planning poker is a consensus-based, gamified technique for estimating the effort of development goals. Each team member makes estimates by playing numbered cards face-down on the table, instead of saying it out loud. The cards are then revealed and the estimates discussed with the whole team.Traditional cost estimations can take a lot of time, and they distract from the development team. There are various approaches that you can take in completing your cost estimations.

Burn Rate Cost Approach

The first approach is to work with your sprint session burn rate and period. Considering the sprint session has a fixed number of time resource units, it can be simple to work out the true cost if the cost of each resource is obtained. Depending on what costs are available to you, the approach can either be:

Average cost per person per hour. This is the simplest approach as you multiply the hours of each resource utilized during the sprint by the average cost you have been supplied. As an example, if you have one part-time resource and one full-time resource at $100 an hour (assuming 8 hours a day), a two week sprint would be (40 hours x $100) + (80 hours x $100) giving you a $12 000 per 2-week sprint cost.

Specific cost per person. This approach would require some additional calculations, where you will need to derive an hourly cost per person based on their annual salary cost. Once you’re down to an hourly rate, the calculation is the same as average cost per hour.

While this budgeting is a straightforward approach, its major challenge or downfall, is that it is heavily dependent on calculating the correct burn-down rate or scoring each agile task accurately. It also requires the tasks to have been estimated before you can turn the sprint cost into a project or solution cost. This only solves one part of the problem.

Another issue is that it doesn’t solve for the additional costs outside of the sprint planning. You will need to extend your costing model to provide for testing hours, administration hours, meeting hours and design hours.

Precision-alignment approach

Another approach is more budget orientated and less estimation orientated, and requires a set of business outcomes that are prioritized.

This practical example is based on an article by Debbie Madden writing for Harvard Business Review. Let’s assume you’re building an online retail shop for clothes. This business requirement can be broken down into a handful of areas that translate to major solution tasks, such as:

A landing page for marketing

A search function

A checkout function

Product pages

A customer knowledgebase

Order management system for customer agents

The next task is to then estimate, based on previous experience or some guidance from developers, what each task would take:



Task                               Time                        Budget



Store landing page                    2 - 4 weeks                   $20k - $40k

A search function                     4 - 6 weeks                   $40k - $60k

A checkout function                 6 – 8 weeks                  $60k - $80k

Product pages                           3 – 6 weeks                  $30k - $60k

A customer

knowledgebase                         2 – 4 weeks                  $20k - $40k

Order management

system                                      4 – 8 weeks                  $40k - $80k


This gives a first-sweep budget range of $210 000 - $360 000. Despite this wide range, the business can already make a decision if the minimum budget exceeds the resources available for this project, or is way under resources available. If the range is too broad for the business, you continue with the next step.Take all the tasks, and assign a priority to each one, which allows a distinction between ‘must haves’ and ‘optional maybes’:


Task                                    Time                  Budget              Priority


Store landing page                         2 - 4 weeks              $20k - $40k                 5

A search function                          4 - 6 weeks              $40k - $60k                 3

A checkout function                      6 – 8 weeks             $60k - $80k                 2

Product pages                                3 – 6 weeks             $30k - $60k                 1

A customer                                    2 – 4 weeks             $20k - $40k                 6

Knowledgebase 

Order management                        4 – 8 weeks            $40k - $80k                 4

system 

   

Blend to your environment



Both approaches take different directions but provide useful budgeting information for your agile project. You can combine elements of both approaches depending on how you have implemented agile principles in your organization. For example, if your agile environment is mature and you need to provide mid project sprint costs, the first approach is ideally suited. If your environment is less mature and the project is at an early stage, the second approach might be more suited as it quickly delivers cost approximations at the right stage of the process.

After the budget, comes discipline.

Two things will happen once you enter your project: you will either use fewer resources (time, money, etc.) or you will use more. Either way, daily management of the project and timely updating of your stakeholders is critical.

The situation that needs the most discipline and feedback is when you have detected that the project budget was under provisioned. Many times this is not a simple case of making mistakes during the budgeting process, but rather unexpected obstacles occurring during the project execution such as:

Delays caused by 3rd parties beyond your control

Rework that was unexpected

Resource unavailability, such as illness

External cost shocks, such as currency fluctuations

How to determine the project management model ?

                         

                   

                   

                           When the project management office is faced with the business case of a project and needs to decide on which project methodology is best to use, there are key areas that need to be evaluated in making this recommendation and some of the key areas to review include:

  Project Characteristics

o  Requirements – how rigid and defined are the requirements?

o  Effort/duration – How long is the planned project duration? >6 months, >12 months, >18 months?

o  Interfacing systems – How many interfacing systems are in scope? How complex are these interfaces?

o  Regulatory compliance – Are there any compliance requirements that provide restrictions or additional requirements for the project team?

o  Project inter-dependencies – How many other projects are running concurrently? What is the impact to the key decision-makers? Are they any overlaps with project resources?

 Sponsor Characteristics

o  Sponsor buy-in – Does the project have the right level of sponsorship? Are they committed to the mission of the project?

o  Sponsor time commitment – Is the sponsor dedicated and willing to support the project as needed?

o  Training for agile – Is there an investment for training the team/organization in agile?

o  Periodic validation – Will the sponsor be available to participate in key validation sessions?

o  Project Resources

o  Team size – How large is the team? Can it be broken down into teams of 8 to 12 people?

o  Resource dedication – Are key resources dedicated to the project? If not, can parameters around resource availability be established and supported?

o  Technology/business domain knowledge – How well do team members know the product being delivered? Is their domain expertise at the level that it will not impede the team's velocity?

o  Collaboration – Does the project environment foster collaboration? Are there tools in place to facilitate project team collaboration (e.g., video conferencing, shared document repositories, and so forth)

o  Co-location – How many of the team members are co-located? How many are distributed to different locations?

o  Testing – automated – Are there any automated testing capabilities?

Agile Awareness and Acceptance

o  Training at all levels – Has the organization committed to training the executive, project team, and subject matter experts in agile?

o  Ability to apply agile techniques for all aspects of the project – Is the project management team committed to the values of agile and to the techniques being used?

o  Coaches are available – do not do it alone – Are there agile coaches available to support the project team?

By answering these questions, you will be able to choose the correct project management model. Project scope dictates the conditions that the right methodology has to meet. Every model has its benefits and downsides, and each can be more or less suitable for a certain type of software projects.

Keep in mind the scope, risks, and obligations of your project, and you will be able to choose what’s right exactly for you.

The Journey begins

As an IT Professional I have weared different hats as Developer,Business analyst,Scrum Master,Architect,Product Consultant.I published few articles in LinkedIn.Looking at the positive response I received,I decided to start this blog.We normally do ControlAltDelete and relax,for a change let me ControlAltConstruct :)

Blogging gives an opportunity to hone the skills of your trade.My IT experience,projects I handled ,articles I have read & analysed,Interviews I attended all these years ,I will be explaining these concepts in a coherent way in par with Technical trends.For me learning must not be a burden It must be fun as well as upgrading your knowledge.Grab a Coffee,check out my posts ! Leave your valuable feedback . By the way where did I leave my mouse !!!!