Why should Scrum be used?

What is Scrum?

Scrum is not a fully-featured project management methodology. Rather, it describes an approach to Agile management with a focus on project teams, short “sprints” and daily stand-up meetings.

While it borrows the principles and processes from Agile, Scrum has its own specific methods and tactics for dealing with project management.

“Agile is the philosophy and Scrum the methodology. While Scrum is agile, agile isn’t scrum.”

The Scrum approach places the project team in front and center of the project. Often, there is no project manager. Instead, the team is expected to be self-organizing and self-managing. This makes it ideal for highly focused and skilled teams, but not so much for others.

Advantages of Scrum

1. Scrum “sprints”: The Scrum approach is heavily focused on 30-day “sprints”. This is where the project team breaks down a wishlist of end-goals into small chunks, then works on them in 30-day sessions with daily stand-up meetings. This makes it easy to manage large and complex projects.
2. Fast paced: The “sprint” approach with its 30-day limit and daily stand-up meetings promotes rapid iteration and development.
3. Team-focused: Since the project team is expected to manage itself, Scrum teams have clear visibility into the project. It also means that project leaders can set their own priorities as per their own knowledge of their capabilities.

Besides these, it has all the benefits of Agile – rapid iteration and regular stakeholder feedback.

Disadvantages of Scrum

1. Scope creep: Since there is no fixed end-date, nor a project manager for scheduling and budgeting, Scrum can easily lead to scope creep.
2. Higher risk: Since the project team is self-managing, there is a higher risk of failure unless the team is highly disciplined and motivated. If the team doesn’t have enough experience, Scrum has a very high chance of failure.
3. Lack of flexibility: The project-team focus means that any resource leaving the team in-between will hugely impact the net results. This approach is also not flexible enough for large teams.

Scrum is best for

The Scrum approach is best for highly experienced, disciplined and motivated project teams who can set their own priorities and understand project requirements clearly. It has all the flaws of Agile along with all its benefits. It works for large projects but fails if the project team itself is very large.

Scrum values

Below diagram depicts the core values of the Scrum framework.

Commitment

1. This is not about the expectation that all scope will be delivered, no matter
2. Commitment is about dedication and applies to actions, the effort, not the final result
3. Maximum possible effort for achieving the goal and will be transparent
4. Commitment towards –
   1. Quality
   2. Collaboration
   3. Learning
   4. Professionalism
   5. Excellence
   6. Self-organize
   7. Improvement
   8. Transparency

Focus

1. Focus on what is most important now
2. Future is highly uncertain, focus on YAGNI – “You aren’t gonna need it”
3. Focus on the simplest thing

Openness

1. Be transparent, inspect in order to make sensible adaptation
2. Open about our work, progress, problems, and learnings
3. Open for people and working with people
4. Acknowledging people to be people, and not resources, robots or replaceable machinery
5. Open to collaborate with stakeholders and wider environment
6. Open in sharing feedback and learn from one another
7. Open for change

Respect

1. Respect for people, their experience and their personal background
2. Respect different opinions, we might learn from it
3. Respect for our sponsor by not building features that nobody will use
4. Respect for users by fixing their problems and quality product
5. Respect for wider environment by not behaving as an isolated island in the world
6. Respect each other’s skills and expertise

Courage

1. Courage to not build features that nobody wants
2. Courage in admitting requirements will never be perfect
3. Courage in admitting that no plan can capture reality and complexity
4. Courage to not deliver undone features
5. Courage to share risks and benefits
6. Courage in sharing information that might help team and the organization
7. Courage to change direction

Roles, Artifacts, and Events in the Scrum Framework

Below diagram depicts various roles and their correlation in the Scrum framework.

Roles

Various roles that comprise of scrum framework are:

Scrum Master

A Scrum Master is a team leader and facilitator who helps the team members to follow agile practices so that they can meet their commitments. The Scrum Master is responsible for ensuring Scrum is understood and enacted.

A Scrum Master serves the Scrum Team

1. Lead by example. Be the first one to be vulnerable. Be a living demonstration of team assets and scrum values. Admit your missteps.
2. Create an environment of safety. Encourage debate, support it and keep it productive. Use coaching techniques like open questions.
3. Facilitate Consensus. Try to have key decisions made clear at the end of team discussions, making responsibility and deadlines clear.
4. Learn to read the room. Be connected without being present.
5. Show patience. Be okay with silence. Let the team take action.
6. Restrain from solving. Reveal, not resolve. Be careful not to steer the team towards premature resolution of conflict to protect people. Help team members develop conflict resolution skills.
7. Be comfortable with failure. Team decisions may not lead to the anticipated outcome. This is part of learning and growth.
8. Care for people. Listen to them without judgement. Assume positive intent. Meet them where they are and help them find the next step.
9. Show low tolerance for organizational impediments.

Below diagram depicts the misunderstood stances of a scrum master

Stances of a scrum master

Stances of a scrum master are:

1. Servant Leader
2. Coach
3. Facilitator
4. Teacher
5. Mentor
6. Manager
7. Impediment Remover
8. Change Agent

Scrum Master as a Servant Leader

1. Setting up Scrum as a servant process, not a commanding process
2. Guiding the Development Team towards self-organization
3. Leading the team through healthy conflict and debate
4. Shielding the team from disturbance and external threats
5. Helping the team make visible, remove and prevent impediment
6. Creating transparency by radiating information via Scrum events and artifacts

Scrum Master as a Coach

1. Coaching the Individual in –
   1. Focusing on mindset and behavior
   2. Using Scrum well
   3. Taking next step in his/her Agile journey
2. Coaching the Team in –
   1. Creating a learning culture
   2. Changing mindset for continuous improvement
   3. Problem solving and conflict resolution
3. Coaching the organization in –
   1. Collaborating with the Scrum team
   2. Doing product management with a focus on business value
   3. Delivering high quality and valuable products

Scrum Master as a Facilitator

1. Facilitate the Scrum framework process and the continuous improvement of the process
2. Facilitate the integration of Scrum team into the wider organization
3. Facilitates the Scrum events to be purposeful and effective
   1. Daily Scrum – an atmosphere where healthy peer pressure occurs on delivering quality, commitment and addressing impediments
   2. Sprint Planning – collaboration between the Development Team and the Product Owner, keeping a strong focus on delivering value
   3. Sprint Review – Scrum team, sponsors and stakeholders collaborate to work as One team with the same purpose
   4. Sprint Retrospective – a safe atmosphere in which “elephant in the room” is addressed

Scrum Master as a Teacher

1. Teach Agile during the team start-up
2. Teach the Scrum team about Empiricism
3. Teach about Scrum to Scrum team and other stakeholders
4. Teach the difference between Scrum the Best practices
5. Teach the team about the self-organization
6. Team the team about removing impediments
7. Teach the team about the importance of the product vision
8. Team the team about visualizing progress
9. Teach the Product Owner about Backlog Management
10. Teach the team to have fun

Scrum Master as a Mentor

1. Shu – Follow the Rules
   1. Scrum Master acts as a teacher
   2. Shares knowledge and skills
   3. Provide instructions on “How to do”
2. Ha – Break the Rules
   1. Offers new perspectives and possibilities
3. Ri – Be the Rule
   1. Act as a counsellor
   2. Give advice whenever asked for it

Scrum Master as a Manager

1. Manages impediments
2. Manages the process
3. Manages the boundaries of self-organization
4. Manages the team’s health
5. Manages the culture

Scrum Master as a Impediment Remover

1. Respect the self-organizing capability of the development team
2. Creating environment where Development Team feel safe to raise impediments
3. Understand the meaning of “Impediment”
4. Don’t wait until the Daily Scrum
5. Improve transparency by using the Impediment board
6. Be bold and creative in removing impediments

Scrum Master as a Change Agent

1. Creating an environment that allows the spirit of Scrum to thrive
2. Leading and coaching the organization in its Scrum framework adoption
3. Helping employees and stakeholders understand and enact Scrum development
4. Causing change that increases the productivity of Scrum Team
5. Working with other Scrum Masters to increase the effectiveness of Scrum in the organization
6. Planning Scrum implementation within the organization

Scrum Master Service to the Product Owner

1. Finding techniques for effective Product Backlog management.
2. Helping the Scrum Team understand the need for clear and concise Product Backlog items.
3. Understanding product planning in an empirical environment.
4. Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value.
5. Understanding and practicing agility.
6. Facilitating Scrum events as requested or needed.

Scrum Master Service to the Development Team

1. Coaching the Development Team in self-organization and cross-functionality.
2. Helping the Development Team to create high-value products.
3. Removing impediments to the Development Team’s progress.
4. Facilitating Scrum events as requested or needed.
5. Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

Scrum Master Service to the Organization

1. Leading and coaching the organization in its Scrum adoption.
2. Planning Scrum implementations within the organization.
3. Helping employees and stakeholders understand and enact Scrum and empirical product development.
4. Causing change that increases the productivity of the Scrum Team.
5. Working with other Scrum Masters to increase the effectiveness of the application of Scrum framework in the organization.

Scrum Team

It is the team which works for SDLC of the application. This team includes developers, testers, technical lead, product owner and scrum master. Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment.

1. They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
2. Development Teams are cross-functional, with the skills as a team necessary to create a product Increment;
3. Scrum framework recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
4. Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing or business analysis; there are no exceptions to this rule.
5. Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

Product Owner

A Product Owner drives the product from business perspective and is the one who decides and defines requirements, prioritize their values and release dates. Product owner is also involved in iteration planning and release planning meetings.

1. Clearly expressing Product Backlog items;
2. Ordering the items in the Product Backlog to best achieve goals and missions;
3. Optimizing the value of the work the Development Team performs;
4. Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next;

Artefacts

Sprint Backlog

1. Sprint backlog consists of the selected product backlog items and a plan to deliver them.
2. Selected Product Backlog items are often decomposed.
3. Work for the Sprint emerges.
4. Development team members sign up for work, they aren’t assigned.
5. Development team members may modify the Sprint Backlog anytime, as they see fit.

Product Backlog

The product backlog is a list of all the product features generally defined by “user stories”. User stories define everything potential users want to do on the site. There are many tools to keep track of your project backlog, both analogue and digital options.
After all user stories are created, they are ranked based on the priority and grouping on the stories. Grouping is done based on the inter-dependencies of the stories

Events

Sprint

Agile projects are broken down into small, consistent time intervals. These intervals are referred to as sprints.
Sprints are time-boxed iterations that serve iterative-incremental development.

1. All development is done within a sprint
2. A Sprint contains the time-boxed scrum events
3. A Sprint is one month or less, and it is best to have a consistent duration
   1. Sprint length is determined by acceptable planning horizon
4. Scrum knows no phases, only Sprints
   1. No testing, hardening, release, analysis Sprints

The entire point of Scrum Framework is to create a Done increment

A sprint has a time duration of 1 – 3 weeks depending on the extent of the overall project. Before each sprint, there is a sprint planning meeting. This meeting determines what the goals are for that sprint. Based on the team velocity, a set of features are pulled from the top of the backlog. During the sprint, no features are added, and the sprint goals don’t change

Sprint Planning

This is the first meeting of every sprint and the amount of work which can be achieved in the sprint is decided in this meeting depending on the team velocity. User stories are assigned to the dedicated team as per the requirement and analysis.

Daily Scrum

Every morning of the sprint the project team gets together for a short (under 15 minute) meeting. This meeting takes place at the same time every day and includes everyone on the project.

1. 15-minute time-box daily event.
2. Consistent place and time.
3. Development team inspects their progress toward the Sprint goal
4. Development team creates a plan for the next 24 hours.
5. Not a problem-solving meeting.
6. Not a status meeting.

Each person on the team is tasked to answer 3 simple questions:

• What did you do yesterday?
• What you are going to do today?
• Any blockers or dependencies in your way?

Sprint Review/ Retrospective Meeting

At the end of every sprint, A Sprint Retrospective meeting takes place with a functional demo of the user stories that has been completed during the sprint. The sprint review meeting brings together the project team and other project stakeholders like the client to present the work that was completed.

1. Scrum Team inspects how the last sprint went
   1. People, relationships, process, tools
   2. Definition of “Done”
2. Scrum team selects actionable improvements for implementation in next Sprint.

Scrum events quick reference

The post Is Scrum a Framework or Methodology? appeared first on Argil DX.

– Official React Documentation

Glossary:

React JS and React have been used interchangeably throughout the blog and mean the same thing.

React Native: React code that is usable across the web and  mobile.

Angular: MVC framework for UI.

Transpiler: A type of compiler that takes the source code of a program written in one programming language as its input and produces the equivalent source code in another programming language. Transpiler and compiler can be used interchangeably.

DOM: Document Object Model is a tree of HTML objects.

Note: This blog has been written entirely from my perspective and is what I feel as a newbie to the world of React.

Let’s get started.

There’s a lot of good buzz about React out there.

It seems like React JS has become a library many want to try out but somehow, it’s always out of reach. This blog is aimed towards the audience who is looking for a perfect mix of theory and hands-on.

What is React?

React provides you a templating language and some function holders to primarily render HTML. That’s all React yields, HTML. React is mainly the view layer. React is listed in the same verticals as other JavaScript frameworks but ‘React vs Angular’ doesn’t make sense at all because they aren’t directly comparable. Angular is a complete framework (including the view layer).

Is it worth the hype? Why is it getting so popular?

These are some of the benefits which make React JS standout among its contemporaries:

• Easy to learn and easy to use:  Being able to do awesome things is great, but only if you don’t have to spend the rest of your life becoming perfect in a new technology. React is easy to learn and easy to use and comes with a good supply of documentation and an exponentially growing community.

  
  A Github Stars History for Angular, React & Vue (Source)

• Components: Everything in React is a component (will be explained later on). They are like the basic building blocks for your application . Components help you break your design into smaller parts that can be worked upon.
• The Virtual DOM: One of the really cool parts of React is the virtual DOM. Usually, when you develop an app that has a lot of user interaction and data changes, you have to carefully notice how your app’ design is going to influence performance. Even with quick client side browsers, extensive DOM manipulation can be a performance deteriorator and result in an annoying user experience. Worse, because the DOM is tree-structured, simple changes at the top level can cause huge problems. React caters this by using a virtual DOM. This is, as the name implies, a virtual representation of the DOM. Any new view changes are first performed on the virtual DOM, which lives in memory and not on your screen.

An efficient algorithm then determines the changes made to the virtual DOM to identify the changes that need to be made to the real DOM. It then determines the most suitable way to make these changes and then applies only those changes to the real DOM. This ensures a minimum update time to the real DOM, providing higher performance and a cleaner user experience all around.

All that is fine but what’s up with all that jargon ?

• Component: A React app comprises of components. A component is a reusable piece of code which defines how some features should look. All the parts you see in the below picture can be broken down into different components like the button, the display panel, all clubbed as a single component.
• Properties (props): We can pass data to our components that remain unchanged throughout the lifecycle of that component. We can even pass methods as data in our props.
• State: A state, as the name suggests, defines the state of a component. Unlike props, they can change on user-based interactions and internal calculations. Think of them as observable data that control the behaviour of the component. 
• JSX: It is basically a flavour of JS that can constitute HTML as well. It is highly intelligible. JSX (JavaScript Extended) is not understood by the browser. So, the browser doesn’t freak out, we use a transpiler like Babel which converts JSX into regular JS and renders HTML out of it.

We will take up something to code on React in the next part of this blog…

My view about React Js 

Coming from JAVA background and having noob level knowledge about fronted (JS, CSS, HTML) lingo, React JS didn’t feel like something that couldn’t be done. A basic syntax of JS (maybe ECMA 6) is what you need to know to get started.

Effort required is a lot less as compared to other JS libraries and frameworks ( Angular for example).
Also when you know that you are getting into something that is largely industry friendly and has a great developer community, it just feels the right thing to do.
React JS when combined with react-router and react-bootstrap, serves as a complete package.

When I first encountered JSX as HTML being written inside JS, the idea itself sounded crazy. I thought why would anybody want that. But
after spending some time with it, everything made a lot of sense. The ability to re-render components based on state changes in the most efficient way is what makes React stand apart.

The post Beginners’ Guide to React JS appeared first on Argil DX.

In order to begin making a decision, you must evaluate how important these AEM implementation services are for your firm and your long-term goals. You must step into the shoes of both boutique and larger AEM system integrators to understand how they view your company within their entire portfolio. Larger firms may have more experience because of their more expansive network and resources, but that comes at a substantial cost for clients–splitting these resources and sharing time.

First and foremost, when selecting what type of business to work with, consider how much work and attention you will get out of each dollar you spend. Larger enterprises have at least double and often many more clients than boutique firms. This means that everything the larger firm has to offer will have to be divided amongst their whole pipeline. With larger AEM implementation companies, that means a greater divisor. Businesses looking for AEM implementation services want dedicated attention, so whenever there is a problem, it can be resolved as quickly and efficiently as possible. If attention is the function of time divided by number of clients, then it is clear that smaller firms are the best choice if you require innovative and dedicated solutions.

Secondly, it is essential to consider the economic factor while doing a boutique versus larger implementer comparison. Specifically, how much a firm will value the amount you are paying them to result in a higher level of prioritization. The money you pay a business to handle your services will always be worth more to the smaller firm than the larger one. You want your deal to be gold for the company managing your services.

Furthermore, as a small firm offering AEM implementation services, we are truly invested in our client’s success and interpersonal relationships. People we work with mean more to us than simply being a source of revenue or a mechanism to hit profitability targets; we care about your business as much as you do, and we will strive to perform our best for mutual triumph.

In order for an AEM system integrator to see you as a key client and a massive opportunity, your deal size has to be massive compared to the other clients. This would mean that the money you are giving the business matters for that business to succeed. With larger firms, your deal size is a small fraction of their portfolio and likely equal to other clients, meaning that they don’t give your project much value.

Larger companies offering AEM implementation services have a variety of clients. This means they have to optimize systems and strategies to be implemented across the board for each client they have. Rather than fitting the system for the client, these firms fit clients into the systems. Even if their clients don’t necessarily fit in those “system boxes”, a larger firm will find a way to make their clients fit the firm’s process, not the other way around.

The other cost of having larger firms try to fit you into their systems is that these large businesses will be stubborn and refuse to adjust their strategies resulting in a lack of creativity. With your project, you desire the AEM implementer to adapt their work to fit your needs. Your case can be extremely specialized, and the result you get may not be optimal for the strategies you need. Creativity is the key to obtaining the best results.

Another point to consider is that if you choose to work with a large business, the majority of the people working on your case are junior and lower-level partners. With boutique firms, you have direct access to its top developers. The founder has oversight on all accounts, and higher, senior-level persons do the bulk of the work to ensure quality AEM implementation service. This means less chances for mistakes and/or miscommunication. When you call into these boutique AEM implementation firms, you have a higher likelihood of speaking with a senior representative or even a founding partner than you do at a larger firm.

Also, boutique firms work to ensure that they hire and keep the best resources because they can’t run the risk of sunk costs from a developer or tester not producing the needed results. For this, you know that everyone staffed on your project has gone through extensive interview and training processes to make sure they are the best possible candidates to be working at those firms.

Larger AEM implementation companies have their perks. With more experience comes more exposure to multiple industries and integrations, but an increased risk of inexperienced developers working on your project. Infrastructure and systems have been tested on a number of clients, and they have been optimized several times. With more experience comes more knowledge to be used in creating the best services. Larger companies have the ability to see which systems work and don’t with other clients. This allows them to optimize as they have an abundance of clients to churn through.

Both sides have their advantages. Working with larger firms for AEM implementation services grants you access to more experience because of the firm’s more expansive network and resources. You also feel confident that the systems have been tested and optimized therefore less likelihood of failure. With small firms you have greater emphasis to detail and dedication to quality service, especially from senior staff members. Since smaller firms have fewer clients, you are valued more highly and receive more customized attention. Ultimately, you must consider how important these implementation services are for your firm and your long term goals and make a decision from there.

The post Working with Boutique Versus Large Implementers for AEM Implementation Services appeared first on Argil DX.

Regardless of the response code, your customers will see the same content. However, there are things that happen behind the scenes that could impact the performance of your site and may endanger your site. If you’re using Adobe Dispatcher to cache your AEM/CQ5-served content, Dispatcher only caches content which has a 200 response code. If your content responds with a 404 (or other error code), Dispatcher doesn’t cache it.

Imagine a scenario in which a user typos a page name (hmoe.html rather than home.html) in the URL for your site. They receive a “Page Not Found” response and that page responds with a 200 code. Dispatcher will now cache that page (hmoe.html) on your web server. Since the page doesn’t really exist on your site, there will never be a request to clear that page from your dispatcher cache. It will sit there until it is manually deleted or until its parent page is deactivated. It’s probably not a very big page… Maybe 20 KB. However, imagine that 500 users per month make similar typos on URLs. That would be 500 errant pages in your Dispatcher cache per month (assuming none of the typos have already been cached). These pages will likely stay on your web servers’ drives for a very long time. Eventually, it could cause your drives to fill up which, at the very least, would prevent new content from being cached and at the worst, could cause your web server to stop serving content.

You might say that it’s unlikely enough “Page Not Found” pages would be served to cause your drives to fill up. You might be right. However, imagine another scenario; a more nefarious scenario. A person (let’s call them a hacker) could become aware of the fact that your site’s “Page Not Found,” responds with a 200 code which could cause it to be cached (not only by your systems, but if your site uses a CDN, that would also cache it). It wouldn’t take a very sophisticated hacker to repeatedly ping your site with random page names which continue to cache and fill up your web servers’ drives.

Here’s how to check how your “Page Not Found” page responds… Determine the URL of a page which you know is served by AEM/CQ5. Let’s use the example http://www.abcd.com/content/home.html. Change the page name (home) to a name that you know doesn’t exist on your site (example: blah). So your new URL will be http://www.abcd.com/content/blah.html. Browse to /response-check.html and enter your new URL into the box provided and click “Check Response.” It should provide you with the response code that the URL returns. If it’s 200 (and you know the page should not exist), it will likely take a development effort to get AEM/CQ5 to respond with the appropriate 404 response code.

This is just one of the many hidden issues, which are not readily apparent to your marketing team or to your customers, which might exist on your AEM/CQ5 implementation. Nevertheless, if this type of issue was to be exploited, you can be sure that it would affect your customers and that marketing would take note. Take a few minutes to test your Page Not Found response and then sign up for the security scanner to scan your AEM/CQ5-based website for other security issues.

Looking for security experts who can take care of your AEM-based website’s vulnerability issues? Feel free to contact us.

The post Is a Misconfigured “Page Not Found” Jeopardizing Your Website? appeared first on Argil DX.