Delivering Hybrid IT Value

The “hybrid cloud may be garnering increased interest and adoption, but it is already giving way to new terms such as hybrid IT and hybrid enterprise,” writes Eileen Yu on ZDNET. Hybrid IT? Where have we heard this term before?

In 2014, Computerworld.com predicted that businesses would need to fill one or more of five hybrid-IT roles in order to succeed. “It’s clear that the 2014 corporate agenda will be dominated by the integration of big data analytics, cloud computing, mobile technology, and social media into the enterprise,” wrote Stephanie Overby in Computerworld New Zealand. She adds, “The differentiator will not be the technology itself, but the business value it delivers.”

It seems that hybrid IT is still here two years later, growing bigger in the cloud, and still focused on business value.

Delivering value is not new to Agile- and Scrum-certified professionals. What continues to be new is the emphasis. Overby wrote, “It won’t be about the ability to simply configure and run a server. Or develop software in isolation. Context will be king.” She says, “Employers will aggressively pursue workers with multi-dimensional talent—combinations of technology, domain, business, process, and people skills, orchestrated in a proper balance to deliver specific solutions.”

Writing for Computerworld’s American online magazine, Patrick Thibodeau put this another way back in 2014: “Employers want workers who understand the business and technology. This trend is increasing the mix of requirements to get an IT job. [One industry expert] estimates that by 2017, 50% of the IT roles will require business knowledge.” The growing adoption of the hybrid cloud indicates that this trend is still active.

The hybrid roles Overby discusses include “enterprise architects who get the cloud,” “security professionals with marketing skills” and “software engineers that do more than generate code.” The question of where to find these people becomes important, as does the question of how to provide a work environment in which these employees succeed.

IT professionals who already fit one or more of the hybrid roles may already exist, but how is a company going to find that coding pro who can use his or her business sense to “bring structure to unstructured” collections of meta-data? One place to look is for individuals with Scrum experience.

A thoughtful look at this trend as it continues through 2017 reveals that Scrum can provide what savvy corporations and IT professionals need.

Scrum uses cross-functional teams in which “team members are generalist/specialists in that they have knowledge of various fields and are experts in at least one,” according to A Guide to the Scrum Body of Knowledge (SBOK™) by SCRUMstudy. Scrum Teams are also self-organizing and “beyond their subject-matter expertise, it is the soft skills of team members that determine the success of self-organizing teams,” says the SBOK™ Guide. This matches closely with the “multi-dimensional talent — combinations of technology . . . and people skills” listed by Overby.

As each increment of the service, product or desired result is demonstrated by the Scrum Team to the Product Owner and customers, each team member develops a keen business sense and orientation. At any point in the development process, the Scrum Team member is able to articulate the business value of the particular task he or she is producing.

As part of a self-organizing team, Scrum Team members take ownership of the processes and schedules needed to complete their project. They develop domain and process skills that, as Overby says, are “orchestrated in a proper balance to deliver specific solutions.”

As a part of a cross-functional team, each member commits to backing up other workers. While being an expert in an area needed for the project, each worker will also learn an area in which another team member is the expert. The aim here is to be able to substitute for that person in those cases when a team member is not present.

Companies do not have to go searching for individual professionals with hybrid talents; they can “breed” their own. With the implementation of Scrum in the workplace, its processes and best practices will begin to develop cross-functionality within the organization and within individuals right away. While members of cross-functional teams will be learning from each other and expanding their skills and knowledge sets, the company will have the benefit of hybrid talent being supplied by the team as a whole.

Scrum Teams are “able to foster an environment of independent thinking and group decision-making in order to extract the most benefits from the structure,” according to the SBOK™ Guide. While Scrum is helping some employees become “security professionals with marketing skills,” Scrum Teams with both types of professionals provide that integration of skills and understanding immediately.

Accrediting organizations such as SCRUMstudy can put both companies and professionals in touch with professional training providers that specialize in Scrum and Agile.

As hybrid IT becomes an increasingly important part of hybrid cloud enterprises, companies using Scrum will soar.

Works Cited

A Guide to the Scrum Body of Knowledge (SBOK™ Guide). http://www.scrumstudy.com/overview-of-sbok.asp

Overby, Stephanie. (1/24/2014) “5 hybrid IT roles your business needs to succeed in 2014; Employers will aggressively pursue people with talent in several areas this year.” Computerworld. Retrieved on 1/27/2014 fromhttp://www.computerworld.co.nz/article/536519/5_hybrid_it_roles_your_business_needs_succeed_2014/?ref=suggest_headline

Thibodeau, Patrick. (1/21/2014) “5 reasons why your IT job search is getting harder.”Computerworld. Retrieved on 1/6/2016 from http://www.computerworld.com/article/2486720/it-careers/5-reasons-why-your-it-job-search-is-getting-harder.html

Yu, Eileen. (5/11/2015) “What hybrid cloud? It’s hybrid IT.” ZDNET. Retrieved on 1/5/2016 fromhttp://www.zdnet.com/article/what-hybrid-cloud-its-hybrid-it/

Four Tools for Fantastic Project Vision Creation

Question: What’s a camel?

Answer: A horse designed by a committee.

Sometimes a Project Vision Statement can become clumsy-looking and all-inclusive like a camel, when what was needed is a sleek, powerful racehorse. Using the right tools skillfully can keep your Project Vision Statement thoroughbred thin.

A Guide to the Scrum Body of Knowledge (SBOK™) suggests four tools for the Create Project Vision process: Project Vision Meeting, JAD sessions, SWOT Analysis and Gap Analysis. With some soft skills and reliance on the dozen or more inputs possible for this process, you can keep the statement focused and usable.

The Project Vision Meeting

This meeting pulls together the Program Stakeholders, Program Product Owner, Program Scrum Master and Chief Product Owner or company equivalents. These participants help identify the business context, business requirements and stakeholder expectations in order to develop an effective Project Vision Statement. Scrum believes in closely engaging and collaborating with all business representatives to get their buy-in for the project and to deliver greater value.

JAD Sessions

A Joint Application Design (JAD) Session is a requirements gathering technique. It is a highly structured, facilitated workshop that enables Stakeholders and other decision makers to arrive at a consensus on the scope, objectives and other specifications of the project.

Each session consists of methods for increasing user participation, speeding development and improving specifications. Relevant Program Stakeholders, Program Product Owner, Program Scrum Master and Chief Product Owner often use these sessions to outline and analyze desired business outcomes and focus their vision for the Scrum project.

SWOT Analysis

SWOT is a structured approach to project planning that helps evaluate the Strengths, Weaknesses,Opportunities and Threats related to a project. This type of analysis helps identify both the internal and the external factors that could impact the project. Strengths and weaknesses are internal factors, whereas opportunities and threats are external factors. Identification of these factors helps stakeholders and decision makers provide direction to the processes, tools and techniques to be used to achieve the project objectives. Conducting a SWOT Analysis allows the early identification of priorities, potential changes and risks.

Gap Analysis

This tool is a technique used to compare the current, actual state with some desired state. In an organization, it involves determining and documenting the difference between current business capabilities and the final desired set of capabilities. A project is normally initiated to bring an organization to the desired state, so conducting a Gap Analysis would help decision makers determine the need for a project. A Gap Analysis can look at current offerings and identify opportunities for products that are lacking in a particular market. Likewise, it can be used to identify missing software functionalities that can be developed into profitable products or services.

 

The main steps of a Gap Analysis to identify the difference between current business capabilities and the final desired set of capabilities

With these tools, that Project Vision Statement can be the race-winning thoroughbred every company needs.

To learn more about the changing trends in the world of Scrum and Agile, visit SCRUMstudy.

Various Aspects of Scrum

Scrum is a framework for collaborative effort of the team on some of the very complex software projects. It is the most widely-used subset of Agile. The Scrum principles are the fundamental guidelines for applying Scrum framework. The Scrum framework drives on the goals of giving utmost business value in least time.

Various Scrum aspects are derived and are very essential to be addressed and managed throughout a Scrum project. Here are the five Scrum aspects as mentioned in theSBOK™ Guide

• Organization: Understanding defined roles and responsibilities in a Scrum project is very important for ensuring the successful implementation of Scrum. Scrum roles fall into two broad categories; Core Roles (which includes Product Owner, Scrum Master, Scrum Team) and Non-core Roles (which includes Stakeholder, Scrum Guidance Body, Vendors, Chief Product Owner, Chief Scrum Master)
• Business Justification: Business justification in Scrum is based on the concept of Value-driven Delivery. It is impossible to guarantee project success at completion, irrespective of the size or complexity of a project.
• Quality: Quality is defined as the ability of the completed product or deliverables to meet the Acceptance Criteria and achieve the business value expected by the customer. The Scrum Guidance Body may also provide guidelines about quality which may be relevant to all Scrum projects in the organization.
• Change: Every project, regardless of its method or framework used, is exposed to change. Scrum projects welcome change by using short, iterative Sprints that incorporate customer feedback on each Sprint’s deliverables. This enables the customer to regularly interact with the Scrum Team members, view deliverables as they are ready, and change requirements if needed earlier in the Sprint.
• Risk: Risk is defined as an uncertain event or set of events that can affect the objectives of a project and may contribute to its success or failure. Risks should be identified, assessed, and responded to basing on two factors: the probability of each risk’s occurrence and the possible impact in the event of such occurrence.

SCRUMstudy certification courses offer a detailed description of all these Scrum aspects. Please visit www.scrumstudy.com for more details on SCRUMstudy certifications.

Quality Planning and Technical Debt

Developing functionality of highest priority to the customer at first is one of the major principles of Scrum. This approach allows the Scrum team to focus keenly on the quality planning as they get the required time to categorize the essential functionality according to the customer’s requirements.

What is Technical debt?

The technical debt, which is also referred to as code debt or design debt, which refers to work that the Scrum teams prioritize lower, omits, or do not complete as they work toward creating the primary deliverable. Technical debt is a very big challenge with some traditional project management techniques where development, testing, documentation, etc. are done sequentially and often-times by different persons, with no one person being responsible for any particular Working Deliverable. As a result, technical debt accrues, leading to significantly higher maintenance, integration, and product release costs in the final stages of a project’s release.

Why does Technical debt occur?

The technical debt increases over time and must be paid in the future. Here are some of the key reasons for technical debt to occur:

• Quick-fix and building deliverable that do not comply with standards for quality, security, long-term architecture goals, etc.
• Lack of coordination among different team members, or if different Scrum Teams start working in isolation, with less focus on final integration of components required to make a project or program successful
• Inadequate or incomplete testing
• Poor sharing of business knowledge and process knowledge among the stakeholders and project teams
• Improper or incomplete documentation
• Too much focus on short-term project goals instead of the long-term objectives of the company. This oversight can result in poor-quality Working Deliverable that incur significant maintenance and upgrade costs.

How to control/reduce the Technical debt?

Quality planning has one of its important benefits in terms of reducing the Technical debt. In order to maintain a minimal amount of technical debt it is important to define the product required from a Sprint and the project along with the Acceptance Criteria, any development methods to be followed, and the key responsibilities of Scrum Team members in regards to quality. Any technical debt is not carried over beyond a Sprint, because there should be clearly defined Acceptance and Done Criteria. The Scrum Guidance Body may also include documentation and definition of processes which help in decreasing technical debt.

Visit www.SCRUMstudy.com

Importance of Sprint Backlog in a Scrum Project

What is a Sprint Backlog? Is it a baseline, a record or a report? Baseline is a project document, which, defines aspects of the project and, once approved, is subject to change control. It is used to measure project’s actual performance as against planned targets. A record maintains information on the progress of the project. A report provides snapshots of the status of different aspects of a project at a given point of time or for a given duration.

To answer this question, we need to understand what a Sprint Backlog is, its purpose and composition. The Scrum Team creates the Sprint Backlog and Sprint Burndown Chart using the User Stories and the Effort Estimated Task List during Sprint Planning Meeting. During Sprint Planning Meeting, the User Stories, which are approved, estimated, and committed during the Approve, Estimate, and Commit User Stories process, are taken up for discussion by the Scrum Team. Each Scrum Team member also uses Effort Estimated Task List to select the tasks they plan to work on in the Sprint, based on their skills and experience. The list of the tasks to be executed by the Scrum Team in the upcoming Sprint is called the Sprint Backlog.

It is common practice in Scrum that the Sprint Backlog is represented on a Scrumboard or task board, which provides a constantly visible depiction of the status of the User Stories in the backlog. Also included in the Sprint Backlog are any risks associated with the various tasks. Any mitigating activities to address the identified risks would also be included as tasks in the Sprint Backlog. Once the Sprint Backlog is finalized and committed to by the Scrum Team, new user stories should not be added – however, tasks that might have been missed or overlooked from the committed user stories may need to be added. If new requirements arise during a Sprint, they will be added to the overall Prioritized Product Backlog and included in a future Sprint.

Another tool associated with the Sprint Backlog is the Sprint Burndown Chart. It is a graph that depicts the amount of work remaining in the ongoing Sprint. The initial Sprint Burndown Chart is accompanied by a planned burndown. The Sprint Burndown Chart should be updated at the end of each day as work is completed. This chart shows the progress that has been made by the Scrum Team and also allows for the detection of estimates that may have been incorrect. If the Sprint Burndown Chart shows that the Scrum Team is not on track to finish the tasks in the Sprint on time, the Scrum Master should identify any obstacles or impediments to successful completion, and try to remove them. A related chart is a Sprint Burnup Chart. Unlike the Sprint Burndown Chart which shows the amount of work remaining, the Sprint Burnup Chart depicts the work completed as part of the Sprint.

So, it is difficult to categorize the Sprint Backlog as a baseline, record or a report. And as Scrum professes minimum documentation, Sprint Backlog fulfills purposes of more than one project document. For more information on Scrum framework, you can read the Scrum Body of Knowledge (SBOK Guide). It can be downloaded for free in SCRUMstudy website:http://www.scrumstudy.com/download-free-buy-SBOK.asp

The story behind the origin of Scrum

In the mid 80’s, Hirotaka Takeuchi and Ikujiro Nonaka defined a flexible and all-inclusive product development strategy where the development team works as a unit to reach a common goal. They described an innovative approach to product development that they called a holistic or “rugby” approach, “where a team tries to go the distance as a unit, passing the ball back and forth.” They based their approach on manufacturing case studies from various industries. Takeuchi and Nonaka proposed that product development should not be like a sequential relay race, but rather should be analogous to the game of rugby where the team works together, passing the ball back and forth as they move as a unit down the field. The rugby concept of a “Scrum” (where a group of players form together to restart the game) was introduced in this article to describe the authors’ proposal that product development should involve “moving the Scrum downfield”.

Ken Schwaber and Jeff Sutherland elaborated on the Scrum concept and its applicability to software development in a presentation at the Object-Oriented Programming, Systems, Languages & Applications (OOPSLA) conference held in 1995 in Austin, Texas. Since then, several Scrum practitioners, experts and authors have continued to refine the Scrum conceptualization and methodology. In recent years, Scrum has increased in popularity and is now the preferred project development methodology for many organizations globally.

To learn more about the changing trends in the world of scrum and agile, visit SCRUMstudy.

Understanding a Scrum Project

Recently Scrum has gained immense popularity and attention among the management and development methodologies. So let us see what a Scrum Project is all about.

A Scrum project involves a collaborative effort to create a new product, service, or other result as defined in the Project Vision Statement. Projects are impacted by constraints of time, cost, scope, quality, resources, organizational capabilities, and other limitations that make them difficult to plan, execute, manage, and ultimately succeed. However, successful implementation of the results of a finished project provides significant business benefits to an organization. It is therefore important for organizations to select and practice an appropriate project management methodology.

Scrum is one of the most popular Agile methodologies. It is an adaptive, iterative, fast, flexible, and effective methodology designed to deliver significant value quickly and throughout a project. Scrum ensures transparency in communication and creates an environment of collective accountability and continuous progress. The Scrum framework, as defined in the SBOK™, is structured in such a way that it supports product and service development in all types of industries and in any type of project, irrespective of its complexity.

A key strength of Scrum lies in its use of cross-functional, self-organized, and empowered teams who divide their work into short, concentrated work cycles called Sprints. Figure 1-1 provides an overview of a Scrum project’s flow.

The Scrum cycle begins with a Stakeholder Meeting, during which the Project Vision is created. The Product Owner then develops a Prioritized Product Backlog which contains a prioritized list of business and project requirements written in the form of User Stories. Each Sprint begins with a Sprint Planning Meeting during which high priority User Stories are considered for inclusion in the Sprint. A Sprint generally lasts between one and six weeks and involves the Scrum Team working to create potentially shippable Deliverables or product increments. During the Sprint, short, highly focused Daily Standup Meetings are conducted where team members discuss daily progress. Toward the end of the Sprint, a Sprint Review Meeting is held during which the Product Owner and relevant stakeholders are provided a demonstration of the Deliverables. The Product Owner accepts the Deliverables only if they meet the predefined Acceptance Criteria. The Sprint cycle ends with a Retrospect Sprint Meeting where the team discusses ways to improve processes and performance as they move forward into the subsequent Sprint.

To learn more about the scrum projects, visit www.SCRUMstudy.com