Leading IT Transformation – Workshop 19 (Agile Practices)
The Appleton Greene Corporate Training Program (CTP) for Leading IT Transformation is provided by Ms. Drabenstadt MBA BBA Certified Learning Provider (CLP). Program Specifications: Monthly cost USD$2,500.00; Monthly Workshops 6 hours; Monthly Support 4 hours; Program Duration 24 months; Program orders subject to ongoing availability.
If you would like to view the Client Information Hub (CIH) for this program, please Click Here
Learning Provider Profile
Ms. Drabenstadt is a Certified Learning Provider (CLP) at Appleton Greene and she has experience in Information Technology, Information Governance, Compliance and Audit. She has achieved an MBA, and BBA. She has industry experience within the following sectors: Technology; Insurance and Financial Services. She has had commercial experience within the following countries: United States of America, Canada, Australia, India, Trinidad, and Jamaica. Her program will initially be available in the following cities: Madison WI; Minneapolis MN; Chicago IL; Atlanta GA and Denver CO. Her personal achievements include: Developed Trusted IT-Business Relationship; Delivered Increased Business Value/Time; Decreased IT Costs; Re-tooled IT Staff; Increased IT Employee Morale. Her service skills incorporate: IT transformation leadership; process improvement; change management; program management and information governance.
MOST Analysis
Mission Statement
An agile methodology refers to practices that focus on continuous improvement, flexibility, increased productivity, and efficiency to accelerate the progress of a project or the organization as a whole. Adopting an agile methodology can help accelerate the digital transformation process by enabling significant improvements in the process and introducing innovative ways of achieving the desired results. Organizations that adopt agile practices are better at prioritizing their tasks, aligning their IT goals with their business goals, and improving measurability. All of these contribute to the success of an IT transformation program. Agile practices are also known to improve employee morale and reduce the risks in a project. Agile methodology recognizes that technology is not the only priority in IT transformation. Rather business value comes first. It is important to start the transformation process knowing why and how it will help add value to the business. The agile approach accepts and encourages change. It gives the process enough flexibility to test and switch if the business’ goals or priorities change at any point. Agile practices require continuous learning, collaborations, and improvements through small, incremental steps. It divided work into smaller, more productive sprints to ensure that every little goal achieved takes the team closer to the bigger goal. Agile practices also encourage better communication and transparency through daily updates and an efficient reporting system that makes it easy to track the progress. All these factors help in improving the quality of work and reducing the chances of failure, thus reducing the overall cost of the program.
Objectives
01. Agile Challenges: departmental SWOT analysis; strategy research & development. Time Allocated: 1 Month
02. Extreme Programming (XP): departmental SWOT analysis; strategy research & development. Time Allocated: 1 Month
03. Kanban: departmental SWOT analysis; strategy research & development. Time Allocated: 1 Month
04. Scrum: departmental SWOT analysis; strategy research & development. Time Allocated: 1 Month
05. Disciplined Agile Delivery (DAD): departmental SWOT analysis; strategy research & development. Time Allocated: 1 Month
06. Lean Development: departmental SWOT analysis; strategy research & development. Time Allocated: 1 Month
07. Scaled Agile Framework (SAFe): departmental SWOT analysis; strategy research & development. 1 Month
08. Feature-Driven Development (FDD): departmental SWOT analysis; strategy research & development. Time Allocated: 1 Month
09. Crystal: departmental SWOT analysis; strategy research & development. Time Allocated: 1 Month
10. Dynamic Systems Development Method (DSDM): departmental SWOT analysis; strategy research & development. Time Allocated: 1 Month
Strategies
01. Agile Challenges: Each individual department head to undertake departmental SWOT analysis; strategy research & development.
02. Extreme Programming (XP): Each individual department head to undertake departmental SWOT analysis; strategy research & development.
03. Kanban: Each individual department head to undertake departmental SWOT analysis; strategy research & development.
04. Scrum: Each individual department head to undertake departmental SWOT analysis; strategy research & development.
05. Disciplined Agile Delivery (DAD): Each individual department head to undertake departmental SWOT analysis; strategy research & development.
06. Lean Development: Each individual department head to undertake departmental SWOT analysis; strategy research & development.
07. Scaled Agile Framework (SAFe): Each individual department head to undertake departmental SWOT analysis; strategy research & development.
08. Feature-Driven Development (FDD): Each individual department head to undertake departmental SWOT analysis; strategy research & development.
09. Crystal: Each individual department head to undertake departmental SWOT analysis; strategy research & development.
10. Dynamic Systems Development Method (DSDM): Each individual department head to undertake departmental SWOT analysis; strategy research & development.
Tasks
01. Create a task on your calendar, to be completed within the next month, to analyze Agile Challenges.
02. Create a task on your calendar, to be completed within the next month, to analyze Extreme Programming (XP).
03. Create a task on your calendar, to be completed within the next month, to analyze Kanban.
04. Create a task on your calendar, to be completed within the next month, to analyze Scrum.
05. Create a task on your calendar, to be completed within the next month, to analyze Disciplined Agile Delivery (DAD).
06. Create a task on your calendar, to be completed within the next month, to analyze Lean Development.
07. Create a task on your calendar, to be completed within the next month, to analyze Scaled Agile Framework (SAFe).
08. Create a task on your calendar, to be completed within the next month, to analyze Feature-Driven Development (FDD).
09. Create a task on your calendar, to be completed within the next month, to analyze Crystal.
10. Create a task on your calendar, to be completed within the next month, to analyze Dynamic Systems Development Method (DSDM).
Introduction
What is Agile?
Agile is the capacity to innovate and adapt to change. It is a strategy for navigating a complex and chaotic environment and ultimately prospering in it.
The name “Agile” was chosen by the writers of the Agile Manifesto to describe the entire concept because it embodied the adaptability and capacity for change that were crucial to their methodology.
It basically comes down to considering how you can comprehend what is happening in the environment you are in right now, recognize the uncertainty you are experiencing, and determine how to react to it as you go.
Agile software development: what is it?
Scrum, Extreme Programming, and Feature-Driven Development are just a few examples of frameworks used in agile software development (FDD).
Agile software development encompasses more than just techniques like test-driven development, stand-up meetings, pair programming, and sprints.
The phrase “agile software development” refers to a variety of frameworks and procedures built on the values and tenets outlined in the Manifesto for Agile Software Development and its supporting Twelve Principles:
It’s generally a good idea to live by these values and principles when approaching software development in a particular way and to use them to guide you in determining the best course of action for your specific situation.
Agile differs from traditional methods of software development in part because it places special emphasis on the people executing the job and their interactions with one another. Collaboration between self-organizing cross-functional teams using best practices for their context leads to solutions.
The Agile software development community places a lot of emphasis on self-organizing teams and cooperation.
That does not imply that managers do not exist. It implies that groups might come up with their own strategies for handling problems.
It denotes the cross-functional nature of those teams. Teams don’t necessarily need to have defined roles; rather, while assembling a team, it’s important to check that everyone has the necessary skill sets.
A position is still available for managers. Managers ensure that team members have the appropriate skill sets or acquire them. Managers create the conditions necessary for the team to succeed. Most of the time, managers take a backseat and allow their team figure out how to provide products, but they intervene when the teams make an effort but are unable to solve problems.
When most teams and companies begin using Agile development, they prioritize the methods that promote teamwork and task organization, which is fantastic. Another important set of technical practices, on the other hand, that specifically deal with designing software in a way that helps your team manage with uncertainty, are less usually used but should be. You shouldn’t disregard those technical procedures because they are crucial.
A Short History of Agile
Here is a look at how Agile came to be, how it got the name Agile, and what happened after that. To understand where things stand today, it’s critical to consider the origins of Agile software development.
Agile is a Mindset
The values and concepts of the Agile Manifesto serve as the foundation for the agile mindset. These beliefs and principles offer direction on how to bring about change, react to it, and handle ambiguity.
You could claim that the Agile Manifesto’s opening line, “We are revealing better ways of producing software by doing it and helping others do it,” sums up the entire concept.
Try anything you believe might work when faced with uncertainty, seek feedback, and make adjustments as needed.
When doing this, keep the values and principles in mind. When choosing frameworks, strategies, and techniques to engage with your team and provide value to your clients, let your context be your guide.
What are Agile Methodologies?
What does the notion of Agile techniques mean if Agile is a mindset? You might find it useful to have a precise definition of approach before responding to this query.
A methodology, according to Alistair Cockburn, is the set of rules that a team decides to abide by. This implies that each team will have its own methodology, which will be distinct from the methodologies of other teams in either minor or significant ways.
Hence, Agile techniques are the practices that a team choose to adopt in accordance with Agile values and principles.
I thought Scrum and XP were Agile techniques, you’re presumably saying. Alistair referred to those ideas as a framework. They undoubtedly originated from the technique of a particular team, but when they were made universal to be used by other teams, they became frameworks. These frameworks assist teams in deciding where to begin with their methodologies, but they shouldn’t be the methodology itself. The team’s use of a framework will constantly need to be modified so that it is appropriate for the situation.
What about Agile Project Management or Agile Business Analysis?
Those participating in software development activities but who did not personally produce software searched for a means to understand how these Agile concepts applied to their field of work as Agile Software Development gained popularity.
Software engineers (together with a tester) wrote the Agile Manifesto and the 12 Principles to solve problems they encountered. Agile can be used in numerous contexts if you consider it to be a mentality.
When you do that, agile is now a noun. It explains how you go about doing a particular task. Because of the reasons mentioned above, it does not produce a new methodology.
Asking “How might we execute project management in a way that allows us to create and respond to change and cope with uncertainty” will help you better grasp Agile project management. Together, Agile Alliance and Project Management Institute (PMI) researched this issue to produce the Agile Practice Guide (Available to Agile Alliance Members).
Asking “How might we undertake business analysis in a way that allows us to create and respond to change and cope with uncertainty” will help you better grasp Agile business analysis. In order to develop the Agile Extension to the Business Analysis Body of Knowledge, Agile Alliance and the International Institute of Business Analysis (IIBA) jointly investigated this question (Available to Agile Alliance Members).
What is Business Agility?
The two ideas mentioned above are two instances of an effort to take Agile “outside of software.” The contemporary Business Agility movement is the product of those efforts.
Those who desire Business Agility ask themselves, “How might we build and manage our business in a way that allows us to create and respond to change and deal with uncertainty,” if you take the concept of Agile as a mindset further.
Business agility might be defined as the understanding that for individuals inside an organization to operate with an Agile attitude, the entire organization must support that mindset. Before the business altered its structure and operations to function in an uncertain environment, agile software development was never truly agile.
Key Agile Concepts
Below are a few key Agile concepts.
User Stories: The team breaks the work into functional units known as “user stories,” in conjunction with the client or product owner. Each user narrative is anticipated to add something valuable to the final product.
Daily Meeting: The team meets every day at the same time to update everyone on information that is essential for coordination: each team member briefly explains any “finished” contributions and any challenges they have encountered.
Personas: The team creates in-depth, fictitious biographies of hypothetical users of the future product when the project requires it, such as when user experience is a key determinant in project outcomes.
Team: A “team” in terms of agile is a small group of individuals allocated to the same project or effort, almost all of whom work full-time. A small percentage of team members might work part-time or have additional obligations.
Incremental Development: The majority of Agile teams prefer to utilize an incremental development strategy, which in an Agile setting means that each iteration of the product improves on the one before it by including user-visible functionality.
Iterative Development: Agile projects are iterative insofar as they intentionally allow for “repeating” software development activities, and for potentially “revisiting” the same work products.
Milestone Retrospective: Once a project has been running for a while or at its conclusion, the entire permanent team (not just the developers) devotes one to three days to a thorough examination of the key moments that have occurred.
What Kinds of Agile Methodologies Are There?
As was previously mentioned, the term “agile” refers to techniques and best practices for planning projects in accordance with the ideals and guidelines outlined in the Agile Manifesto. Agile can be implemented in a variety of ways, and there are numerous approaches to select from. Some of the most popular Agile frameworks are listed here.
Kanban
Teams can see the progress made thus far and what’s coming up next thanks to the straightforward, visual project management method known as kanban. The primary management tool for Kanban projects is a Kanban board, which divides tasks into three columns: “To Do,” “Doing,” and “Done.”
Scrum
In many aspects, Scrum and Kanban are similar. Similar to a Kanban board, a Scrum board is how Scrum commonly organizes tasks into columns based on progress. Scrum concentrates on segmenting projects into sprints and only planning and controlling one sprint at a time, in contrast to Kanban. Scrum master and product owner are two further distinctive project responsibilities.
Extreme Programming (XP)
In order to facilitate agile software development initiatives, Extreme Programming (XP) was created. Similar to the Scrum process, it emphasizes continuous development and customer delivery and employs intervals or sprints. Yet XP additionally includes 12 auxiliary procedures unique to the field of software development:
• Planning game
• Small releases
• Customer acceptance tests
• Simple design
• Pair programming
• Test-driven development
• Refactoring
• Continuous integration
• Collective code ownership
• Coding standards
• Metaphor
• Sustainable pace
Feature-driven development (FDD)
Another Agile framework that is specialized to software is feature-driven development. According to this methodology, software models must be produced every two weeks, and every aspect of the models must have a development and design strategy. It is better suited for teams with extensive design and planning skills because it has more stringent documentation requirements than XP. FDD divides projects into five fundamental activities:
• Develop an overall model
• Build a feature list
• Plan by feature
• Design by feature
• Build by feature
Dynamic Systems Development Method (DSDM)
The demand for a standard industry framework for quick software delivery gave rise to the Dynamic Systems Development Method (DSDM). Rework is expected, and any changes to the development process that take place must be reversible. Scrum, XP, and FDD all use sprints, and so does DSDM. This framework is built on the following eight guiding ideas:
• Focus on the business need
• Deliver on time
• Collaborate
• Never compromise quality
• Build incrementally from firm foundations
• Develop iteratively
• Communicate continuously and clearly
• Demonstrate control
Crystal
Agile techniques belonging to the Crystal family include Crystal Clear, Crystal Yellow, Crystal Orange, Crystal Red, etc. Each has a distinct structure. Your decision is influenced by a number of project parameters, including the size of your team, your priorities, and the importance of the project.
Lean Development
Lean development is often grouped with Agile, but it’s an entirely different methodology that happens to share many of the same values. The main principles of the Lean methodology include:
• Eliminating waste
• Build quality in
• Create knowledge
• Defer commitment
• Deliver fast
• Respect people
• Optimize the whole
The Five Principles of Agile IT Transformation
Agile IT transformation is supported by research showing that effective IT transformations result from continuous innovation, which involves dramatically altering business models and capabilities over time, in small steps, and when resources permit. This enables businesses to quickly respond to shifting market conditions and customer demands by launching, learning from, and relaunching digital projects.
Agile IT transformation initiatives embrace five core principles:
Principle 1: start with a transformative vision
63% of company leaders said they don’t properly understand the potential of next-generation technology, according to a recent Gartner survey. Unsurprisingly, only 13% of respondents claimed they have chosen the next significant investment in digital business technology. It is clear why this is the case. The firm needs a transformation vision that would outline its digital strategy and, more significantly, enable it to track its progress and make changes in real time to improve results. The compelling future digital vision must be created, expressed, and communicated by senior management.
Transformation does not occur bottom-up.
Principle 2: focus on building digital customer engagement
Marketers started using digital channels to distribute goods and services in the late 20th century. Product portfolios are evolving into apps today. Legacy business models are put under pressure by customer expectations influenced by digital innovations because consumers rarely accept an experience as satisfactory. As a result, business models must change in order to provide exciting and personalized customer experiences and to maintain engagement. The music industry changed when it adopted a business strategy that overcame the constraints of the physical world in response to what consumers actually wanted—constant access to their favorite music combined with opinions from friends, critics, and the musicians themselves.
Building client connection is the key to effective IT transitions that increase engagement. Different methods are used for digital customer engagement than for conventional digital or marketing projects. They have the following three qualities:
1. Unlike earlier marketing endeavors that were more back-office marketing automation and Customer Relationship Management (CRM) centered, digital technology is developed around the front-end customer experience.
2. Technology and methods cannot be bought as a whole set off the shelf. A digital ecosystem that automates the customer experience through social, data, cloud, and mobile is instead enabled by sets of applications and developing platform technologies.
3. Exposure to new growth opportunities—not by incorporating digital features into already-existing products, but by shifting focus and taking the needs of the digital consumer into account for products and services.
Principle 3: support the vision with secure digital platforms
We seldom ever think about the underlying infrastructure that supports our digital experience when using our mobile devices and tablets. Enterprise Resource Planning systems have shaped and controlled the application landscape in the corporate setting for more than 20 years, leading to monolithic structures, high costs, and constrained flexibility. The Cloud has started to open up the application landscape over the last few years, taking control away from the few oligopolistic traditional development suppliers. Applications today come from numerous novel sources, such as internet marketplaces and catalogs. The world can now appear to be included in an organization’s IT department.
Platforms are the major innovation channel in this context. The necessity for the large research and development teams of the past is decreasing as some of the best innovation in the industry is taking place outside of the company’s doors. With the help of these robust digital platforms’ open Application Program Interfaces (APIs), open datasets, service catalogs, integration frameworks, solution guidance, and collaboration tools, a company can easily establish its own market based on customer-focused solutions that make use of enterprise-grade data and services. Digital platforms enable the intelligent use of Cloud, Big Data, social media, smart “Things,” and mobile devices with an unlimited number of technology partners. To connect the steady and predictable world of business systems with the dynamic, opportunistic environment of digital transformation, leading organizations are gradually deploying digital platforms. On the basis of market or customer change, digital platforms enable business owners, partners, and even customers to quickly construct next-generation products.
While digital platforms and next-gen solutions have made a variety of innovative, affordable, dynamic solutions possible, they have also opened the door to new next-gen risks. Extreme connectivity and open architecture are characteristics of the digital world. Maintaining security and risk management systems has proven difficult for IT departments as a result. The conflict arises from the back-end IT compliance’s innate slowness compared to the quickness and agility of digital platforms. The digital innovation killer, however, is hiding behind an impenetrable firewall, therefore these new threats must be controlled.
Risks relevant to an organization’s particular activity must be given priority. Security is currently the most popular application, thus risk management requires clever technologies that can swiftly identify intrusions and react in real time. The secret to freeing up existing IT assets and fostering digital innovation and growth is secure access to digital platform components. While protecting assets and data is of the utmost importance, the correct strategy will enable the speed, security, and expansion needed in the modern digital economy.
Principle 4: drive insight with data-driven visualization
Modern digital businesses continually collect data as well as connect and visualize that data in a way that produces actionable insights. Understanding and addressing consumer personas and micro segments is the key to releasing real-time data insight for dynamic and unified customer engagement.
Companies often have a solid base of sales transactional data. Yet, the dimensionality that is required to generate insightful demographic, attitudinal, and predictive insights is frequently missing from this data. In addition, using both purchased and publically available data to enhance data is uncommon.
Via statistical graphics, plots, infographics, and dynamic tables and charts, many businesses employ data visualization to effectively and efficiently convey information to people. Users that employ effective visualization can analyze and reason about data and evidence. Data visualization improves accessibility, comprehension, and usability of complicated data. It expedites executive and stakeholder decision-making and comprehension of technologies and capabilities, which lowers rework and, eventually, application development costs.
Source: cohnreznick.com
Principle 5: embrace digital agility to create advantage
Because of the constantly shifting market and client conditions, business leaders frequently struggle to carry out large-scale projects. The traditional business model includes projects with 6–18 month lifecycles and fragmented, non-integrated platforms by business function. By the time a project is finished, the market and the needs of the customers have frequently changed, and the success criteria and ROI are rarely met.
By creating a “digital agility advantage” that enables a firm to adopt market and operational changes as a matter of routine through the use of digital technology, businesses can embrace adaptable differentiation and avoid these problems. Initiatives for digital agility are based on 30-day sprints, with new iterations being developed more quickly and effectively. Using the concept of “learn, launch, re-learn, re-launch,” a company is able to experiment and change continuously, improving the strategy in manageable iterations. Businesses that thrive in the digital age must show that they understand how to be adaptable. In addition, they must be able to manage innovation and governance in an agile manner during execution.
In order to enable a corporation to continuously adapt its digital strategy in response to past performance and program feedback, digital agility enables digital innovation. Best practice businesses often evaluate their level of digital maturity across all capabilities as they look into new ways to spur dramatic growth for their enterprise. Successful transformation management requires a digital innovation framework.
With the large number of internal and external partners, platforms, frameworks, and designs that are used, digital governance offers a difficulty. The work might be implemented globally, which would make geographic management and risk reduction more difficult. Centralized coordination of digital programs is the most typical. Compared to silo, hub, and global organizational methods, this governance structure works better. Radical organizational change is possible when combined with a monitoring program using scorecards and key performance indicators.
Why Agile Drives IT Transformation
Here are the reasons why an agile approach to digitization is effective:
1. Constant communication and collaboration
Employees are expected to follow directions and complete their work quickly in top-down projects with deadlines. As the reputation (and careers) of executives are on the line if the project fails, these environments are prone to becoming fear-driven. Conflict and change communication are discouraged, which frequently leads to subpar projects.
Agile, on the other hand, encourages participation and feedback from the entire team, including IT, non-IT, executives, and occasionally clients, leading to projects that are successful and popular with end users.
2. Trust and accountability between employees and team members
When a business is top-down, decision-makers’ reputations are tied to project performance, and executives dread failure if projects don’t deliver. When executives manipulate performance reports to portray apparent achievement, they could inflate those reports. In contrast, Agile fosters a culture of transparency where each stakeholder feels accountable for the project’s success through whole-team cooperation.
As Gartner reports, businesses move twice as fast on their digital transformation journey once staff and management appreciate the importance of their project.
3. Flexibility
The traditional structure, which employs a waterfall approach, spends costs before adamantly demanding successful outcomes. As there is an imposed deadline and employees are graded on how well they complete top-down standards, disagreement is discouraged. It might be too late to turn around once decision-makers have started on their preplanned excursions without spending more money and time.
Agile, on the other hand, manages risks by segmenting its process into time-boxed sprints, one for each target, and only moving forward after receiving unanimous approval from its team.
4. Continuous improvement
The process of digital transformation is ongoing. Developers are aware that they must regularly review and update their IT systems as laws change or new infrastructure enters the market. This habit of continual process improvement is essential for maintaining systems compliance with changing government rules, including those pertaining to consumer privacy, and for reducing the length of IT defenses against cyber intrusion.
Top-tier industries, such those in the FinTech, Health, Government, or Legal sectors, where even one failure may send them to their knees, require the ability to continuously improve. Until you break down continuous development into smaller, more manageable chunks, it can appear daunting.
5. Customer-centric
Your chances of pleasing your customer increase when you are focused on their needs. A cursory comparison of the Fortune 500 list from more than 60 years ago reveals that owing to market upheaval, nearly 90% of those who were monarchs of their industries vanished. Only companies like Boeing, Campbell Soup, Colgate-Palmolive, General Motors, IBM, Kellogg, and Procter and Gamble who used customer-led innovation succeeded.
Executive Summary
Chapter 1: Agile Challenges
Difficulties are what make life fascinating; overcoming them is what makes life worthwhile, according to a quotation. The same principle holds true for problems with Agile transition.
47% of Agile transitions, according to a research, fail. According to the survey, 67% of these Agile disasters have fatal outcomes. You might feel overpowered by these figures. Certainly, these are significant numbers considering that the majority of modern enterprises rely on Agile for their changes. It is only natural to wonder why it is so difficult to duplicate something that is successful on a team. Why doesn’t the same thing apply to enterprise-level transformation?
It’s critical to understand the obstacles to Agile transformation that each organization may experience. Understanding how to get through obstacles is just as crucial. Let’s discuss the difficulties and possible solutions:
1. Third-Party Influences:
The majority of Agile transformation failures are caused by external forces. These days, many businesses are bound by either fixed-outcome or fixed-price contracts. If not, they are compelled to engage with partners who are unwilling or unable to switch to an Agile Delivery Model. Let’s assume your company uses the Agile delivery system. Nonetheless, you are compelled to cooperate with a noncompliant supplier. Your Agile progress may be hampered in this situation.
2. Culture Shift:
One of the largest obstacles to an Agile transition is a culture shift. Certainly, some refer to Agile as a common attitude or culture rather than a set of procedures. When it comes to transforming or scaling Agile, this approach proves to be both a blessing and a curse. Of course, you believe that the framework chosen is more significant than mentality when it comes to Agile transformation. Nonetheless, developing a common attitude is challenging.
Any culture’s components fit together as a supporting system when discussing it. They stick together to thwart any attempts to alter it. Team-level single-fix adjustments may initially appear to be making progress. On the other hand, over time, the organizational culture’s interconnected elements may prevail. As a result, the adjustment made draws from the organization’s preexisting culture.
3. Getting Buy-in:
Obtaining buy-in is one of the primary obstacles when thinking about Agile transformation issues. Many businesses will begin the Agile transition process with one strategy. They implement Agile techniques in a single workspace vertical. In other words, they begin with fewer leaders and smaller teams. Of course, the methodology’s pilot experiment could be a success. Nonetheless, its impact may be severely constrained. The executive team frequently struggles to comprehend the strategic value due to the obstructionist nature. Also, they are unable to comprehend the far-reaching effects of larger Agile transformation initiatives.
4. Dependencies:
Dependencies must be taken into account when tackling the issues of Agile transformation. Your company has a few options for handling dependencies if it wants to become Agile. To handle them, you have the first choice. Alternatively, you may break them. All you will get if you completely ignore them is local optimization.
You can manage the transformation with a team that is not aligned when dependencies are present. Along with the other teams in your organization, you may transform this one. This group can succeed all by themselves. But, everything will go wrong if the team needs to synchronize any dependencies.
There will still be dependencies between the teams in a company, even if every team is Agile. Let’s assume that there is only one underperforming team in this situation. Other teams’ failures might be caused by this team.
5. Communication:
The lack of communication between teams is one of the main obstacles to the Agile transformation. Let’s say you apply Agile concepts to all of your organization’s teams. The change process may be hampered by poor team communication. As a result, problems may ensue. The good news about this difficulty is that it may be easily resolved by organizing regular contact. Not only should team communications be appropriate between teams, but also within teams.
6. Investing in Talents:
Having the necessary skills can only make things easier when it comes to the challenges of Agile transformation. The motivation behind the Agile process is skill, which accounts for this. Some businesses are only able to build empowered, cross-functional teams because they have the best personnel. Companies struggle with Agile transformation because talent strategy is only given secondary consideration.
Effective Agile transformation involves more than just adhering to a framework; it also involves a new way of thinking and acting. Let’s assume that an organization has real agility. This will enable organization personnel to develop their talents and put their competencies to use. They will then make a bigger contribution to the advancement of their workplace!
These difficulties will be covered in greater detail in this course manual, and you will learn how to deal with them should they appear at any time when you are undergoing an IT transition.
Chapter 2: Extreme programming (XP)
XP is an approach to agile software development that emphasizes quality and provides the flexibility required to respond to changing user requirements.
Similar to Agile frameworks, XP encourages quick development cycles to increase agility. Yet it also incorporates many forms of testing and quality assurance into the development process, such as:
• Pair programming, where a second set of eyes reviews code as it’s written
• Unit testing of all code as it’s committed
• Avoiding programming any features until they are required
• Delivering only simple, clear code to streamline collaboration across developers
• Frequent communication with users to react quickly if requirements change
Scrum and Kanban are more fragmented sets of guidelines than XP is. With so many changing aspects, some businesses might want to selectively embrace the XP rules that best suit their needs rather than adopting all of them at once.
XP would be particularly beneficial to companies that:
• Want a laser-focus on the quality of their SAP code
• Have the manpower available to regularly code in pairs
• Want a holistic set of rules they can follow in their agile approach to SAP development
Advantages and disadvantages of XP
XP practices have been debated upon for decades, as its approach and methods are rather controversial in a number of aspects and can’t be applied in just any project. Here, we’ll try to define the pros and cons of XP methodology.
XP pros and cons in a nutshell
Extreme programming advantages
So, the XP framework can be beneficial and help reduce development time and costs for the following reasons:
• Continuous testing and refactoring techniques aid in the development of reliable, efficient systems with less need for troubleshooting;
• The importance of simplicity is writing lucid, concise code that is simple to understand and modify in the future if necessary;
• The use of a minimal, iterative development process means that results may be supplied quickly and that only essential features are created;
• User stories replace lengthy requirements documents, which results in less documentation;
• There is little to no practice of overtime;
• Ongoing communication keeps all team members updated on project progress and offers a high level of visibility and accountability;
• Pair programming has been shown to produce products of higher quality and with fewer problems; most study participants also stated that they enjoyed this type of collaboration more and felt more confident in their work;
• Client involvement ensures customer pleasure because it can immediately affect the development and testing process, giving them the exact outcome they desired.
Extreme programming disadvantages
However, there are a few drawbacks to XP that should be taken into account while picking which framework to choose for your subsequent project:
• It is sometimes difficult to accurately estimate scope, cost, and time since the customer lacks a clear vision of the final product;
• Frequent client meetings frequently consume a significant amount of time that could be used to write actual code;
• Lack of sufficient documentation and unclear requirements and specifications might cause project scope to expand;
• Rapidly switching from conventional software development techniques to extreme programming necessitates considerable structural and cultural changes;
• Due to the human element and character incompatibilities, pair programming takes longer and occasionally fails;
• XP’s application with dispersed teams is limited because it performs best with colocated teams and customers present in person for face-to-face meetings;
• Customers may not always be motivated, available, or knowledgeable enough to contribute to product development. When deadlines are short, it can become stressful because either no useful input is given, or a non-technical person tries to supervise tech specialists who have little to no understanding of the procedure;
• Other issues mentioned by some authors include an emphasis on the code rather than the design, a lack of quality assurance, duplicate code, and subpar outcomes from unskilled developers.
Any business can use the XP concepts in its projects, but it’s crucial to comprehend both the advantages and disadvantages.
Chapter 3: Kanban
Although we’ll be covering Kanban in future workshops, it is important to highlight how Kanban and agile go hand in hand, as Kanban is also an important part of any agile transformation.
What is kanban?
A well-liked framework for implementing agile and DevOps software development is kanban. It necessitates complete transparency of work and real-time capacity communication. Team members can always observe the status of every piece of work thanks to the visual representation of work items on a kanban board.
Although the kanban work approach has been around for more than 50 years, agile and DevOps development teams now use it extensively. Toyota started streamlining its engineering procedures in the late 1940s using a model similar to the one used by supermarkets to fill their shelves. Supermarkets optimize the flow between the supermarket and the customer by stocking precisely the right amount of items to meet demand. The supermarket increases its inventory management efficiency by reducing the quantity of extra stock it must hold at any given time since inventory levels match consumption patterns. The supermarket can still guarantee that the specific item a customer needs is always in stock in the interim.
Toyota used the same method on its production floors with the intention of better matching their enormous inventory levels with the actual material consumption. Workers would transmit a card, or “kanban,” between teams on the manufacturing floor to convey capacity levels in real-time (as well as to suppliers). A kanban, which details the material that is required, the precise quantity of this item, and other information, is passed to the warehouse when a bin of materials utilized on the manufacturing line is emptied. A fresh bin of this material would be waiting in the warehouse when it was sent to the production floor, and the plant would then deliver its own kanban to the supplier. Also, the supplier would have a bin of this specific material ready to be shipped to the warehouse. This procedure still relies on the same “just in time” (or JIT) manufacturing method, even though signaling technology has advanced since the 1940s.
Kanban for software teams
These same JIT techniques can still be used by agile software development teams today by matching the quantity of work in progress (WIP) to the team’s capabilities. Teams benefit from more flexible planning options, quicker results, a more focused effort, and openness throughout the development process as a result.
Chapter 4: Scrum
Although we’ll be covering scrum in future workshops, it is important to highlight how scrum and agile go hand in hand, as scrum is also an important part of any agile transformation.
What is scrum?
Scrum is an agile project management framework that uses a set of values, principles, and practices to assist teams in organizing and managing their work. Scrum enables teams to learn from experiences, self-organize while working on a problem, and reflect on their victories and losses to continuously improve, much like a rugby squad practicing for the big game (thus the name).
Although software development teams employ the scrum most frequently, its ideas and lessons may be applied to many forms of teamwork. This is only one of the many benefits of scrum. Scrum is a set of meetings, tools, and roles that help teams organize and manage their work. It is frequently thought of as an agile project management framework.
Agile vs. scrum
Due to the fact that scrum is built on continuous improvement, an essential component of agile, many people mistakenly believe that scrum and agile are interchangeable terms. Yet, scrum is a methodology for completing tasks, whereas agile is a way of thinking. The core of the agile methodology is modest, frequent releases that enable ongoing, incremental development. You can’t really “go agile” since it takes the entire team’s commitment to alter how they view providing value to clients. But, you may practice incorporating agile ideas into your daily communication and work by using a framework like scrum.
The Scrum Guide and the Agile Manifesto explain how agile differs from the concept of scrum. Four values are outlined in the Agile manifesto:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
Empiricism and lean thinking serve as the foundation for the scrum definition. According to empiricism, knowledge is gained via experience, and choices are based on what is seen. Lean thinking eliminates waste and concentrates on the necessities. Heuristic in nature, the scrum framework is built on ongoing learning and adaptation to changing circumstances. It recognizes that the team will learn from experience and that they do not have all the answers at the beginning of a project. With re-prioritization integrated into the process and brief release cycles, Scrum is designed to enable teams automatically adapt to changing conditions and user requirements so your team can continuously learn and develop.
Scrum is structured but not completely strict. Any organization’s needs can be catered to in terms of how it is carried out. There are numerous views on the precise procedures that effective scrum teams must follow. Whichever framework you decide on, the core principles of effective communication, openness, and commitment to continual development should always be kept in mind. The remainder is up to you.
The scrum team
A scrum team is a compact, adaptable group of individuals committed to meeting agreed-upon product milestones. Usually consisting of 10 persons, a scrum team is small enough to finish a significant amount of work in a sprint. The development team, the scrum master, and the product owner are the three essential roles for a scrum team. Additionally, because agile teams are cross-functional, in addition to developers, the development team also consists of testers, designers, UX experts, and ops engineers.
Chapter 5: Disciplined Agile Delivery (DAD)
Disciplined agile delivery, a component of the disciplined agile toolkit, is an agile method of software development that draws on Scrum, Lean, and other well-known agile methods.
DAD supports the entire delivery lifecycle, as contrast to certain agile models that concentrate on a specific stage of the development process. Another way that DAD differentiates from other agile methodologies is by emphasizing the delivery of complete, consumable solutions rather than the least viable products.
Moreover, DAD is distinctive in that it provides a hybrid methodology that combines components of Scrum, Kanban, XP, and many other agile approaches. As a result, it offers a more comprehensive method of development.
DAD’s ability to scale is a further advantage. DAD may grow across numerous teams and business divisions to bring the advantages of agile to the entire organization, in contrast to agile methodologies like Scrum and Kanban that rely on stand-up meetings and boards that sometimes can’t support larger teams.
DAD is particularly suited to organizations that:
• Need to scale agile to larger teams
• Want to take a more holistic approach to development
• Are already using Scrum or Lean principles, and want to build on them
DAD is part of the Disciplined Agile toolkit.
How did DAD come about?
Scott Ambler and Mark Lines are the creators of DAD. The term was first outlined by Ambler in the 2013 white paper “Going Beyond Scrum: Disciplined Agile Delivery.” Ambler and Lines solidified the concept in their book Choose Your WoW! A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working, which is often cited as the central reference for the term.
The methodology was created by the authors after they studied instances when enterprise-level agility was successful. They understood that scrums could only deal with issues that affected the team as a whole and could not address issues that Agile teams faced on a larger scale. Also, they noted that certain Agile language was ambiguous and inconsistent.
The Disciplined Agile (DA) framework, which was created in 2015 and later evolved into the Disciplined Agile toolkit in 2018, was built on the foundation given by DAD. Later, two more levels were added to the framework: Disciplined DevOps and Disciplined Agile IT (DAIT), resulting in a comprehensive strategy for DevOps and IT processes in the organization. The DAD framework is a collection of Agile frameworks that have the same fundamental objectives. The DAD layer serves as the base layer, while the additional layers are enlarged replicas of it.
Chapter 6: Lean Development
Waste is costly. Paying for things you don’t need, paying for someone to do nothing but talk, or paying for team members to solve a problem that could have been avoided. Lean agile seeks to minimize inefficient processes and tasks for increased effectiveness and lower costs—never compromising on quality. In actuality, lean agile places a high priority on providing value to the consumer with each choice that is taken.
A development approach called lean agile aids teams in finding waste and streamlining procedures. It’s a way of thinking that promotes effectiveness, efficiency, and ongoing progress.
Take into account the fact that you probably produce much better work when your desk isn’t fully cluttered with unnecessary items. Eliminating waste and interruptions creates an orderly workspace and workflow. By helping you concentrate on what matters most, you can work quickly and effectively.
You can read more about the history of lean, the advantages of lean agile, and the five fundamental lean concepts in this course manual.
The development of lean agile
Lean manufacturing’s guiding principles are the foundation of lean agile, often known as lean software development. The idea was implemented in manufacturing to boost profitability by lowering costs rather than relying exclusively on higher sales. A business can save money by cutting waste and improving efficiency, which will boost overall earnings.
Lean agile is an agile methodology that, at its core, is very straightforward: increase productivity by getting rid of waste. Lean agile project management seeks to eliminate all tasks and activities that don’t add genuine value, as opposed to traditional waterfall project management, which mandates a predetermined plan given out by a project manager. This makes it possible for everyone involved in a project or the development of a product to work as effectively as possible.
The Lean Enterprise Institute Inc., established in 1997 by James P. Womack, PhD, is a top source for lean methodology if you’re trying to delve into the background of lean agile. Using lean ideas and practices, it seeks to improve the performance of individuals and teams.
Because they may be used with other agile strategies and software development techniques, lean practices are well-liked. Scaling agile, which is sometimes challenging for large or expanding firms, has a clear applicability with lean agile.
The benefits of lean agile
Waste less time
When processes don’t go smoothly, time is lost. Fast and efficient delivery of goods and services is crucial in lean manufacturing. Nobody should waste time at work, and businesses should strive for shorter lead times without compromising quality.
In every industry, wasting time is expensive, but when working in agile software development, it’s especially crucial to pay attention. A workflow or delivery timeline might be significantly thrown off by even a little congestion or flawed method. Lean agile enables development teams to efficiently manage time so that everyone is employed, no one’s time is wasted, and obstacles are foreseen in advance.
Reduce costs
Businesses can save money by reducing trash. Lean manufacturing originally made sure that businesses always had the appropriate number of supplies, workers, and working hours. By better system and process management, costly wastes like overproduction, overhiring, or simply having too many supplies to store can be reduced.
Any company, regardless of sector, will experience financial savings from increased efficiency. Agile teams continue to optimize operations through continuous waste elimination as part of lean agile.
Improve work quality
Lean agile emphasizes maintaining effective working practices while providing clients and stakeholders with high-quality products. Businesses can maintain their competitiveness when they consciously enhance processes. To ensure that needs are always satisfied or surpassed, lean principles take the customer value of any action or decision into account.
Chapter 7: Scaled Agile Framework (SAFe)
For applying agile principles at an enterprise scale, there is a set of organizational and workflow patterns called the Scaled Agile Framework® (SAFe®). A body of knowledge known as the framework provides systematic direction on roles and responsibilities, how to organize and manage the work, and values to uphold.
SAFe encourages coordination, cooperation, and delivery among numerous agile teams. It was built on the principles of three main bodies of knowledge: systems thinking, lean product development, and agile software development.
SAFe offers an organized method for scaling agile as enterprises expand. To support different degrees of size, SAFe has four configurations: Essential SAFe, Big Solution SAFe, Portfolio SAFe, and Complete SAFe.
In order to assist enterprises in creating better systems and software that better suit the evolving needs of customers, Dean Leffingwell and Drew Jemilo developed SAFe in 2011. Teams delivered software at the time using conventional project management procedures. Yet, as the need to react quickly to shifting market conditions grew, new frameworks appeared to aid companies in enhancing solution delivery throughout their operations, giving rise to SAFe. One of the most widely used scaled agile delivery frameworks today, SAFe is still being improved upon by its global practitioner community.
Scrum is one of many agile approaches that only functions within individual teams. A Scrum of Scrums—a method of managing numerous Scrums collectively across the business—must be established if you wish to expand them to include different business functions.
One method for managing this kind of agile approach at scale is the Scaled Agile Framework. It enables you to extend your agile strategy across many verticals by dividing Scrums and Kanbans across various tiers.
SAFe is distinctive in that it also incorporates elements of DevOps like Release on Demand to quicken development. SAFe, however, may need the creation of entirely new jobs for the organization because it integrates so many different disciplines.
SAFe works best in organizations that:
• Want to apply Agile across the entire business
• Have the headcount to create new roles
• Are interested in combining Agile and DevOps approaches
Chapter 8: Feature-Driven Development
Feature driven development (FDD) may be the solution if you need your software to operate quickly. Fast development cycles and feature-rich systems are provided to organizations thanks to feature driven development, which is always evolving.
What is the history of feature driven development?
Jeff Luca came up with the concept of FDD in 1997 to help a Singapore bank with its software development requirements. He came up with a set of five procedures to cover the development of the model as well as its listing, design, planning, and construction of its characteristics.
Why is feature driven development popular?
Because to its reputation as being both agile and practical, FDD and its five core activities have been utilized to create enterprise software ever since it was first proposed.
It combines the essential benefits of Scrum and eXtreme Programming with model-centric methods like Eric Evan’s Domain-Driven Design and Peter Coad’s modeling in color. Due to its just enough design initially (JEDI) principle, peer evaluations, and dynamic feature teams, it is also easily scalable to big teams.
Feature driven development: the pros and cons
How feature driven development differs from Scrum development is one of the frequently asked questions about it. There are many similarities between feature driven development and scrum, including their collaborative natures, increased communication capabilities, emphasis on high-quality components, and rapid iterative development of features with continuous progress monitoring.
The difference between them is because Scrum does not outline any specific technical practice. Vertical slices of functionality with brief feedback loops are the main focus instead. FDD, on the other hand, focuses on specialized engineering processes with longer feedback loops and a feature team that plays roles that are easily recognizable.
It might be said that FDD was developed by considering the inherent advantages and disadvantages of people. Because it addresses so many of the issues that plague developers so frequently, it has shown to be a highly successful strategy to save large projects. The application’s rapid development process, which uses two-week increments, even allows businesses the option to use it before it is complete. The entire feature list was created with business users’ objectives in mind.
FDD and Scrum Similarities
They both collaborate and are interested in interactions and teamwork. They place a strong emphasis on communication and openness; in fact, one of the three basic tenets of Scrum is openness.
It is simple to monitor progress in a variety of ways and at various scales or granularities.
They both place a strong emphasis on making components of the highest caliber. There shouldn’t be any substandard work or short corners.
FDD vs Scrum Differences
Scrum:
• Does not define any particular design or development techniques, although parts of XP are often used by teams.
• Focus on generating small product increments that can be quickly delivered to a customer
• Much shorter feedback loops
• Self-organizing teams, with a simple structure and set of roles – e.g. no “senior” or “chief” roles.
FDD :
• Detailed design methods
• Domain driven design
• Roles that are more likely to map to an organization’s existing roles, e.g. “chief programmer”
• Longer feedback loops.
Chapter 9: Crystal
Alastair Cockburn created the Crystal agile framework, a group of agile approaches, at IBM in 1991. The agile Crystal framework prioritizes people over processes. Project teams are given the freedom to come up with their own solutions without being limited by specific processes.
Understanding the Crystal agile framework
Cockburn was tasked with developing a framework for software development but instead discovered that project teams relied on a set of best practices to be successful.
Additionally, Cockburn pointed out that the size of the team, as well as the importance and priority of the project, affected each team’s success.
The agile Crystal framework is a simple, adaptable, and human-centered agile method. It is predicated on two key tenets:
1. Project work can be streamlined to increase team productivity.
2. Because each project is different and dynamic, it calls for specific approaches.
Crystal method family members
Depending on the number of participants and the linked project’s level of criticality, a project’s specific characteristics change.
A small team can create a product, for instance, without a lot of status updates and documentation. But, larger teams engaged in more challenging projects would quickly run into communication problems in the absence of adequate documentation.
Cockburn created family members based on size and criticality to help people understand this concept.
By pointing out that each project requires a unique mix of policies, practices, and procedures, he noted that Crystal was “a set of samples that you adjust to your circumstances”.
What Are the Critical Components of the Crystal Agile Framework?
Crystal framework has seven key components, out of which the first three are mandatory, and the rest are optional. They are as follows:
In this course manual, we will discuss these components in more detail.
Chapter 10: Dynamic Systems Development Method (DSDM)
DSDM is an Agile approach that emphasizes the entire project lifecycle. It was developed in 1994 as a result of project managers adopting RAD (Rapid Application Development) asking for additional governance and discipline in this new iterative mode of working.
The success of DSDM is a result of its guiding principle, according to which “every project must be in line with clearly defined strategic goals and concentrate on the early delivery of actual benefits to the business.” The eight principles that underpin this philosophy help teams stay focused and complete projects on time.
The Eight Principles
The Eight Principles of DSDM:
1. Focus on the business need
2. Deliver on time
3. Collaborate
4. Never compromise quality
5. Build incrementally from firm foundations
6. Develop iteratively
7. Communicate continuously and clearly
8. Demonstrate control
With proven scalability to handle projects of all sizes and for every business sector, DSDM is vendor-independent, spans the whole lifecycle of a project, and provides best practice guidelines for on-time, in-budget delivery of projects.
DSDM advocates the use of several proven practices, including:
• Facilitated Workshops
• Modelling and Iterative Development
• MoSCoW Prioritization
• Time boxing
DSDM: A Hybrid Approach to Promote Agility while Delivering Business Value
Since 1994, the Dynamic System Development Method, sometimes known as DSDM, has been effectively employed for quick software development and delivery.
It was agile with an iterative and incremental approach long before the Agile Manifesto was created and went much beyond the team level, making it an agile scaling methodology (not simply a framework) before the word “scaling agile” was even used.
It provides you with a ton of advice, far more than other scaling frameworks, similar to SAFe. When you’re still finding your agile feet, having more to hang onto is a tremendous advantage.
You will find a solid foundation for its concept, principles, responsibilities, and emphasis on successfully and quickly delivering value to your business during your IT transformation in this course manual.
Brief Overview
DSDM incorporates the limitations frequently imposed by corporate cultures and processes while taking the requirement to respond fast into account during the development of the product.
Many of the issues we encounter while managing projects more conventionally are solved by adopting DSDM.
For instance, DSDM regularly facilitates seminars and promotes team interaction, which aids in resolving the inherent communication issues that many projects encounter.
Because delivering 80% of the features working and on time is preferable to attempting to deliver everything late, DSDM emphasizes on delivering on time.
Consumers are people. During the product development process, as their understanding of the product grows, they frequently have second thoughts. In order to better understand client requirements, DSDM involves the customer in the creation of the solution.
Early client interaction helps prevent issues, stops the development of unnecessary features, and ensures the company gets what it needs. Also, it helps to avoid overengineering or embellishing the outcome.
The consumer will receive a return on its investment as quickly as feasible thanks to all of these advantageous effects.
Brief History
DSDM is an incremental and iterative methodology that adheres to the principles of Agile development, including ongoing customer and user participation.
1994 saw the initial release of DSDM. Also, it was developed to provide some discipline to another technique that was being used at the time, the rapid application development approach (RAD).
The early DSDM practitioners understood the advantages and shortcomings of sequential development models like a waterfall and rapid application development.
They sought to bring together RAD’s capacity for producing worthwhile ideas rapidly with an awareness of the larger project context and the requirement for stakeholder engagement.
The DSDM project framework was updated in 2007. Instead of being specifically focused on software development and code creation, it evolved into a more general approach to project management and solution delivery.
The most recent model was released by DSDM in 2014. The updated DSDM manual acknowledged the necessity for DSDM to cooperate with other service delivery frameworks including ITIL, PRINCE2, and PMI’s Body of Knowledge (PMI-BOK).
Curriculum
Leading IT Transformation – Workshop 19 – Agile Practices
- Agile Challenges
- Extreme Programming (XP)
- Kanban
- Scrum
- Disciplined Agile Delivery (DAD)
- Lean Development
- Scaled Agile Framework (SAFe)
- Feature-Driven Development (FDD)
- Crystal
- Dynamic Systems Development Method (DSDM)
Distance Learning
Introduction
Welcome to Appleton Greene and thank you for enrolling on the Leading IT Transformation corporate training program. You will be learning through our unique facilitation via distance-learning method, which will enable you to practically implement everything that you learn academically. The methods and materials used in your program have been designed and developed to ensure that you derive the maximum benefits and enjoyment possible. We hope that you find the program challenging and fun to do. However, if you have never been a distance-learner before, you may be experiencing some trepidation at the task before you. So we will get you started by giving you some basic information and guidance on how you can make the best use of the modules, how you should manage the materials and what you should be doing as you work through them. This guide is designed to point you in the right direction and help you to become an effective distance-learner. Take a few hours or so to study this guide and your guide to tutorial support for students, while making notes, before you start to study in earnest.
Study environment
You will need to locate a quiet and private place to study, preferably a room where you can easily be isolated from external disturbances or distractions. Make sure the room is well-lit and incorporates a relaxed, pleasant feel. If you can spoil yourself within your study environment, you will have much more of a chance to ensure that you are always in the right frame of mind when you do devote time to study. For example, a nice fire, the ability to play soft soothing background music, soft but effective lighting, perhaps a nice view if possible and a good size desk with a comfortable chair. Make sure that your family know when you are studying and understand your study rules. Your study environment is very important. The ideal situation, if at all possible, is to have a separate study, which can be devoted to you. If this is not possible then you will need to pay a lot more attention to developing and managing your study schedule, because it will affect other people as well as yourself. The better your study environment, the more productive you will be.
Study tools & rules
Try and make sure that your study tools are sufficient and in good working order. You will need to have access to a computer, scanner and printer, with access to the internet. You will need a very comfortable chair, which supports your lower back, and you will need a good filing system. It can be very frustrating if you are spending valuable study time trying to fix study tools that are unreliable, or unsuitable for the task. Make sure that your study tools are up to date. You will also need to consider some study rules. Some of these rules will apply to you and will be intended to help you to be more disciplined about when and how you study. This distance-learning guide will help you and after you have read it you can put some thought into what your study rules should be. You will also need to negotiate some study rules for your family, friends or anyone who lives with you. They too will need to be disciplined in order to ensure that they can support you while you study. It is important to ensure that your family and friends are an integral part of your study team. Having their support and encouragement can prove to be a crucial contribution to your successful completion of the program. Involve them in as much as you can.
Successful distance-learning
Distance-learners are freed from the necessity of attending regular classes or workshops, since they can study in their own way, at their own pace and for their own purposes. But unlike traditional internal training courses, it is the student’s responsibility, with a distance-learning program, to ensure that they manage their own study contribution. This requires strong self-discipline and self-motivation skills and there must be a clear will to succeed. Those students who are used to managing themselves, are good at managing others and who enjoy working in isolation, are more likely to be good distance-learners. It is also important to be aware of the main reasons why you are studying and of the main objectives that you are hoping to achieve as a result. You will need to remind yourself of these objectives at times when you need to motivate yourself. Never lose sight of your long-term goals and your short-term objectives. There is nobody available here to pamper you, or to look after you, or to spoon-feed you with information, so you will need to find ways to encourage and appreciate yourself while you are studying. Make sure that you chart your study progress, so that you can be sure of your achievements and re-evaluate your goals and objectives regularly.
Self-assessment
Appleton Greene training programs are in all cases post-graduate programs. Consequently, you should already have obtained a business-related degree and be an experienced learner. You should therefore already be aware of your study strengths and weaknesses. For example, which time of the day are you at your most productive? Are you a lark or an owl? What study methods do you respond to the most? Are you a consistent learner? How do you discipline yourself? How do you ensure that you enjoy yourself while studying? It is important to understand yourself as a learner and so some self-assessment early on will be necessary if you are to apply yourself correctly. Perform a SWOT analysis on yourself as a student. List your internal strengths and weaknesses as a student and your external opportunities and threats. This will help you later on when you are creating a study plan. You can then incorporate features within your study plan that can ensure that you are playing to your strengths, while compensating for your weaknesses. You can also ensure that you make the most of your opportunities, while avoiding the potential threats to your success.
Accepting responsibility as a student
Training programs invariably require a significant investment, both in terms of what they cost and in the time that you need to contribute to study and the responsibility for successful completion of training programs rests entirely with the student. This is never more apparent than when a student is learning via distance-learning. Accepting responsibility as a student is an important step towards ensuring that you can successfully complete your training program. It is easy to instantly blame other people or factors when things go wrong. But the fact of the matter is that if a failure is your failure, then you have the power to do something about it, it is entirely in your own hands. If it is always someone else’s failure, then you are powerless to do anything about it. All students study in entirely different ways, this is because we are all individuals and what is right for one student, is not necessarily right for another. In order to succeed, you will have to accept personal responsibility for finding a way to plan, implement and manage a personal study plan that works for you. If you do not succeed, you only have yourself to blame.
Planning
By far the most critical contribution to stress, is the feeling of not being in control. In the absence of planning we tend to be reactive and can stumble from pillar to post in the hope that things will turn out fine in the end. Invariably they don’t! In order to be in control, we need to have firm ideas about how and when we want to do things. We also need to consider as many possible eventualities as we can, so that we are prepared for them when they happen. Prescriptive Change, is far easier to manage and control, than Emergent Change. The same is true with distance-learning. It is much easier and much more enjoyable, if you feel that you are in control and that things are going to plan. Even when things do go wrong, you are prepared for them and can act accordingly without any unnecessary stress. It is important therefore that you do take time to plan your studies properly.
Management
Once you have developed a clear study plan, it is of equal importance to ensure that you manage the implementation of it. Most of us usually enjoy planning, but it is usually during implementation when things go wrong. Targets are not met and we do not understand why. Sometimes we do not even know if targets are being met. It is not enough for us to conclude that the study plan just failed. If it is failing, you will need to understand what you can do about it. Similarly if your study plan is succeeding, it is still important to understand why, so that you can improve upon your success. You therefore need to have guidelines for self-assessment so that you can be consistent with performance improvement throughout the program. If you manage things correctly, then your performance should constantly improve throughout the program.
Study objectives & tasks
The first place to start is developing your program objectives. These should feature your reasons for undertaking the training program in order of priority. Keep them succinct and to the point in order to avoid confusion. Do not just write the first things that come into your head because they are likely to be too similar to each other. Make a list of possible departmental headings, such as: Customer Service; E-business; Finance; Globalization; Human Resources; Technology; Legal; Management; Marketing and Production. Then brainstorm for ideas by listing as many things that you want to achieve under each heading and later re-arrange these things in order of priority. Finally, select the top item from each department heading and choose these as your program objectives. Try and restrict yourself to five because it will enable you to focus clearly. It is likely that the other things that you listed will be achieved if each of the top objectives are achieved. If this does not prove to be the case, then simply work through the process again.
Study forecast
As a guide, the Appleton Greene Leading IT Transformation corporate training program should take 12-18 months to complete, depending upon your availability and current commitments. The reason why there is such a variance in time estimates is because every student is an individual, with differing productivity levels and different commitments. These differentiations are then exaggerated by the fact that this is a distance-learning program, which incorporates the practical integration of academic theory as an as a part of the training program. Consequently all of the project studies are real, which means that important decisions and compromises need to be made. You will want to get things right and will need to be patient with your expectations in order to ensure that they are. We would always recommend that you are prudent with your own task and time forecasts, but you still need to develop them and have a clear indication of what are realistic expectations in your case. With reference to your time planning: consider the time that you can realistically dedicate towards study with the program every week; calculate how long it should take you to complete the program, using the guidelines featured here; then break the program down into logical modules and allocate a suitable proportion of time to each of them, these will be your milestones; you can create a time plan by using a spreadsheet on your computer, or a personal organizer such as MS Outlook, you could also use a financial forecasting software; break your time forecasts down into manageable chunks of time, the more specific you can be, the more productive and accurate your time management will be; finally, use formulas where possible to do your time calculations for you, because this will help later on when your forecasts need to change in line with actual performance. With reference to your task planning: refer to your list of tasks that need to be undertaken in order to achieve your program objectives; with reference to your time plan, calculate when each task should be implemented; remember that you are not estimating when your objectives will be achieved, but when you will need to focus upon implementing the corresponding tasks; you also need to ensure that each task is implemented in conjunction with the associated training modules which are relevant; then break each single task down into a list of specific to do’s, say approximately ten to do’s for each task and enter these into your study plan; once again you could use MS Outlook to incorporate both your time and task planning and this could constitute your study plan; you could also use a project management software like MS Project. You should now have a clear and realistic forecast detailing when you can expect to be able to do something about undertaking the tasks to achieve your program objectives.
Performance management
It is one thing to develop your study forecast, it is quite another to monitor your progress. Ultimately it is less important whether you achieve your original study forecast and more important that you update it so that it constantly remains realistic in line with your performance. As you begin to work through the program, you will begin to have more of an idea about your own personal performance and productivity levels as a distance-learner. Once you have completed your first study module, you should re-evaluate your study forecast for both time and tasks, so that they reflect your actual performance level achieved. In order to achieve this you must first time yourself while training by using an alarm clock. Set the alarm for hourly intervals and make a note of how far you have come within that time. You can then make a note of your actual performance on your study plan and then compare your performance against your forecast. Then consider the reasons that have contributed towards your performance level, whether they are positive or negative and make a considered adjustment to your future forecasts as a result. Given time, you should start achieving your forecasts regularly.
With reference to time management: time yourself while you are studying and make a note of the actual time taken in your study plan; consider your successes with time-efficiency and the reasons for the success in each case and take this into consideration when reviewing future time planning; consider your failures with time-efficiency and the reasons for the failures in each case and take this into consideration when reviewing future time planning; re-evaluate your study forecast in relation to time planning for the remainder of your training program to ensure that you continue to be realistic about your time expectations. You need to be consistent with your time management, otherwise you will never complete your studies. This will either be because you are not contributing enough time to your studies, or you will become less efficient with the time that you do allocate to your studies. Remember, if you are not in control of your studies, they can just become yet another cause of stress for you.
With reference to your task management: time yourself while you are studying and make a note of the actual tasks that you have undertaken in your study plan; consider your successes with task-efficiency and the reasons for the success in each case; take this into consideration when reviewing future task planning; consider your failures with task-efficiency and the reasons for the failures in each case and take this into consideration when reviewing future task planning; re-evaluate your study forecast in relation to task planning for the remainder of your training program to ensure that you continue to be realistic about your task expectations. You need to be consistent with your task management, otherwise you will never know whether you are achieving your program objectives or not.
Keeping in touch
You will have access to qualified and experienced professors and tutors who are responsible for providing tutorial support for your particular training program. So don’t be shy about letting them know how you are getting on. We keep electronic records of all tutorial support emails so that professors and tutors can review previous correspondence before considering an individual response. It also means that there is a record of all communications between you and your professors and tutors and this helps to avoid any unnecessary duplication, misunderstanding, or misinterpretation. If you have a problem relating to the program, share it with them via email. It is likely that they have come across the same problem before and are usually able to make helpful suggestions and steer you in the right direction. To learn more about when and how to use tutorial support, please refer to the Tutorial Support section of this student information guide. This will help you to ensure that you are making the most of tutorial support that is available to you and will ultimately contribute towards your success and enjoyment with your training program.
Work colleagues and family
You should certainly discuss your program study progress with your colleagues, friends and your family. Appleton Greene training programs are very practical. They require you to seek information from other people, to plan, develop and implement processes with other people and to achieve feedback from other people in relation to viability and productivity. You will therefore have plenty of opportunities to test your ideas and enlist the views of others. People tend to be sympathetic towards distance-learners, so don’t bottle it all up in yourself. Get out there and share it! It is also likely that your family and colleagues are going to benefit from your labors with the program, so they are likely to be much more interested in being involved than you might think. Be bold about delegating work to those who might benefit themselves. This is a great way to achieve understanding and commitment from people who you may later rely upon for process implementation. Share your experiences with your friends and family.
Making it relevant
The key to successful learning is to make it relevant to your own individual circumstances. At all times you should be trying to make bridges between the content of the program and your own situation. Whether you achieve this through quiet reflection or through interactive discussion with your colleagues, client partners or your family, remember that it is the most important and rewarding aspect of translating your studies into real self-improvement. You should be clear about how you want the program to benefit you. This involves setting clear study objectives in relation to the content of the course in terms of understanding, concepts, completing research or reviewing activities and relating the content of the modules to your own situation. Your objectives may understandably change as you work through the program, in which case you should enter the revised objectives on your study plan so that you have a permanent reminder of what you are trying to achieve, when and why.
Distance-learning check-list
Prepare your study environment, your study tools and rules.
Undertake detailed self-assessment in terms of your ability as a learner.
Create a format for your study plan.
Consider your study objectives and tasks.
Create a study forecast.
Assess your study performance.
Re-evaluate your study forecast.
Be consistent when managing your study plan.
Use your Appleton Greene Certified Learning Provider (CLP) for tutorial support.
Make sure you keep in touch with those around you.
Tutorial Support
Programs
Appleton Greene uses standard and bespoke corporate training programs as vessels to transfer business process improvement knowledge into the heart of our clients’ organizations. Each individual program focuses upon the implementation of a specific business process, which enables clients to easily quantify their return on investment. There are hundreds of established Appleton Greene corporate training products now available to clients within customer services, e-business, finance, globalization, human resources, information technology, legal, management, marketing and production. It does not matter whether a client’s employees are located within one office, or an unlimited number of international offices, we can still bring them together to learn and implement specific business processes collectively. Our approach to global localization enables us to provide clients with a truly international service with that all important personal touch. Appleton Greene corporate training programs can be provided virtually or locally and they are all unique in that they individually focus upon a specific business function. They are implemented over a sustainable period of time and professional support is consistently provided by qualified learning providers and specialist consultants.
Support available
You will have a designated Certified Learning Provider (CLP) and an Accredited Consultant and we encourage you to communicate with them as much as possible. In all cases tutorial support is provided online because we can then keep a record of all communications to ensure that tutorial support remains consistent. You would also be forwarding your work to the tutorial support unit for evaluation and assessment. You will receive individual feedback on all of the work that you undertake on a one-to-one basis, together with specific recommendations for anything that may need to be changed in order to achieve a pass with merit or a pass with distinction and you then have as many opportunities as you may need to re-submit project studies until they meet with the required standard. Consequently the only reason that you should really fail (CLP) is if you do not do the work. It makes no difference to us whether a student takes 12 months or 18 months to complete the program, what matters is that in all cases the same quality standard will have been achieved.
Support Process
Please forward all of your future emails to the designated (CLP) Tutorial Support Unit email address that has been provided and please do not duplicate or copy your emails to other AGC email accounts as this will just cause unnecessary administration. Please note that emails are always answered as quickly as possible but you will need to allow a period of up to 20 business days for responses to general tutorial support emails during busy periods, because emails are answered strictly within the order in which they are received. You will also need to allow a period of up to 30 business days for the evaluation and assessment of project studies. This does not include weekends or public holidays. Please therefore kindly allow for this within your time planning. All communications are managed online via email because it enables tutorial service support managers to review other communications which have been received before responding and it ensures that there is a copy of all communications retained on file for future reference. All communications will be stored within your personal (CLP) study file here at Appleton Greene throughout your designated study period. If you need any assistance or clarification at any time, please do not hesitate to contact us by forwarding an email and remember that we are here to help. If you have any questions, please list and number your questions succinctly and you can then be sure of receiving specific answers to each and every query.
Time Management
It takes approximately 1 Year to complete the Leading IT Transformation corporate training program, incorporating 12 x 6-hour monthly workshops. Each student will also need to contribute approximately 4 hours per week over 1 Year of their personal time. Students can study from home or work at their own pace and are responsible for managing their own study plan. There are no formal examinations and students are evaluated and assessed based upon their project study submissions, together with the quality of their internal analysis and supporting documents. They can contribute more time towards study when they have the time to do so and can contribute less time when they are busy. All students tend to be in full time employment while studying and the Leading IT Transformation program is purposely designed to accommodate this, so there is plenty of flexibility in terms of time management. It makes no difference to us at Appleton Greene, whether individuals take 12-18 months to complete this program. What matters is that in all cases the same standard of quality will have been achieved with the standard and bespoke programs that have been developed.
Distance Learning Guide
The distance learning guide should be your first port of call when starting your training program. It will help you when you are planning how and when to study, how to create the right environment and how to establish the right frame of mind. If you can lay the foundations properly during the planning stage, then it will contribute to your enjoyment and productivity while training later. The guide helps to change your lifestyle in order to accommodate time for study and to cultivate good study habits. It helps you to chart your progress so that you can measure your performance and achieve your goals. It explains the tools that you will need for study and how to make them work. It also explains how to translate academic theory into practical reality. Spend some time now working through your distance learning guide and make sure that you have firm foundations in place so that you can make the most of your distance learning program. There is no requirement for you to attend training workshops or classes at Appleton Greene offices. The entire program is undertaken online, program course manuals and project studies are administered via the Appleton Greene web site and via email, so you are able to study at your own pace and in the comfort of your own home or office as long as you have a computer and access to the internet.
How To Study
The how to study guide provides students with a clear understanding of the Appleton Greene facilitation via distance learning training methods and enables students to obtain a clear overview of the training program content. It enables students to understand the step-by-step training methods used by Appleton Greene and how course manuals are integrated with project studies. It explains the research and development that is required and the need to provide evidence and references to support your statements. It also enables students to understand precisely what will be required of them in order to achieve a pass with merit and a pass with distinction for individual project studies and provides useful guidance on how to be innovative and creative when developing your Unique Program Proposition (UPP).
Tutorial Support
Tutorial support for the Appleton Greene Leading IT Transformation corporate training program is provided online either through the Appleton Greene Client Support Portal (CSP), or via email. All tutorial support requests are facilitated by a designated Program Administration Manager (PAM). They are responsible for deciding which professor or tutor is the most appropriate option relating to the support required and then the tutorial support request is forwarded onto them. Once the professor or tutor has completed the tutorial support request and answered any questions that have been asked, this communication is then returned to the student via email by the designated Program Administration Manager (PAM). This enables all tutorial support, between students, professors and tutors, to be facilitated by the designated Program Administration Manager (PAM) efficiently and securely through the email account. You will therefore need to allow a period of up to 20 business days for responses to general support queries and up to 30 business days for the evaluation and assessment of project studies, because all tutorial support requests are answered strictly within the order in which they are received. This does not include weekends or public holidays. Consequently you need to put some thought into the management of your tutorial support procedure in order to ensure that your study plan is feasible and to obtain the maximum possible benefit from tutorial support during your period of study. Please retain copies of your tutorial support emails for future reference. Please ensure that ALL of your tutorial support emails are set out using the format as suggested within your guide to tutorial support. Your tutorial support emails need to be referenced clearly to the specific part of the course manual or project study which you are working on at any given time. You also need to list and number any questions that you would like to ask, up to a maximum of five questions within each tutorial support email. Remember the more specific you can be with your questions the more specific your answers will be too and this will help you to avoid any unnecessary misunderstanding, misinterpretation, or duplication. The guide to tutorial support is intended to help you to understand how and when to use support in order to ensure that you get the most out of your training program. Appleton Greene training programs are designed to enable you to do things for yourself. They provide you with a structure or a framework and we use tutorial support to facilitate students while they practically implement what they learn. In other words, we are enabling students to do things for themselves. The benefits of distance learning via facilitation are considerable and are much more sustainable in the long-term than traditional short-term knowledge sharing programs. Consequently you should learn how and when to use tutorial support so that you can maximize the benefits from your learning experience with Appleton Greene. This guide describes the purpose of each training function and how to use them and how to use tutorial support in relation to each aspect of the training program. It also provides useful tips and guidance with regard to best practice.
Tutorial Support Tips
Students are often unsure about how and when to use tutorial support with Appleton Greene. This Tip List will help you to understand more about how to achieve the most from using tutorial support. Refer to it regularly to ensure that you are continuing to use the service properly. Tutorial support is critical to the success of your training experience, but it is important to understand when and how to use it in order to maximize the benefit that you receive. It is no coincidence that those students who succeed are those that learn how to be positive, proactive and productive when using tutorial support.
Be positive and friendly with your tutorial support emails
Remember that if you forward an email to the tutorial support unit, you are dealing with real people. “Do unto others as you would expect others to do unto you”. If you are positive, complimentary and generally friendly in your emails, you will generate a similar response in return. This will be more enjoyable, productive and rewarding for you in the long-term.
Think about the impression that you want to create
Every time that you communicate, you create an impression, which can be either positive or negative, so put some thought into the impression that you want to create. Remember that copies of all tutorial support emails are stored electronically and tutors will always refer to prior correspondence before responding to any current emails. Over a period of time, a general opinion will be arrived at in relation to your character, attitude and ability. Try to manage your own frustrations, mood swings and temperament professionally, without involving the tutorial support team. Demonstrating frustration or a lack of patience is a weakness and will be interpreted as such. The good thing about communicating in writing, is that you will have the time to consider your content carefully, you can review it and proof-read it before sending your email to Appleton Greene and this should help you to communicate more professionally, consistently and to avoid any unnecessary knee-jerk reactions to individual situations as and when they may arise. Please also remember that the CLP Tutorial Support Unit will not just be responsible for evaluating and assessing the quality of your work, they will also be responsible for providing recommendations to other learning providers and to client contacts within the Appleton Greene global client network, so do be in control of your own emotions and try to create a good impression.
Remember that quality is preferred to quantity
Please remember that when you send an email to the tutorial support team, you are not using Twitter or Text Messaging. Try not to forward an email every time that you have a thought. This will not prove to be productive either for you or for the tutorial support team. Take time to prepare your communications properly, as if you were writing a professional letter to a business colleague and make a list of queries that you are likely to have and then incorporate them within one email, say once every month, so that the tutorial support team can understand more about context, application and your methodology for study. Get yourself into a consistent routine with your tutorial support requests and use the tutorial support template provided with ALL of your emails. The (CLP) Tutorial Support Unit will not spoon-feed you with information. They need to be able to evaluate and assess your tutorial support requests carefully and professionally.
Be specific about your questions in order to receive specific answers
Try not to write essays by thinking as you are writing tutorial support emails. The tutorial support unit can be unclear about what in fact you are asking, or what you are looking to achieve. Be specific about asking questions that you want answers to. Number your questions. You will then receive specific answers to each and every question. This is the main purpose of tutorial support via email.
Keep a record of your tutorial support emails
It is important that you keep a record of all tutorial support emails that are forwarded to you. You can then refer to them when necessary and it avoids any unnecessary duplication, misunderstanding, or misinterpretation.
Individual training workshops or telephone support
Please be advised that Appleton Greene does not provide separate or individual tutorial support meetings, workshops, or provide telephone support for individual students. Appleton Greene is an equal opportunities learning and service provider and we are therefore understandably bound to treat all students equally. We cannot therefore broker special financial or study arrangements with individual students regardless of the circumstances. All tutorial support is provided online and this enables Appleton Greene to keep a record of all communications between students, professors and tutors on file for future reference, in accordance with our quality management procedure and your terms and conditions of enrolment. All tutorial support is provided online via email because it enables us to have time to consider support content carefully, it ensures that you receive a considered and detailed response to your queries. You can number questions that you would like to ask, which relate to things that you do not understand or where clarification may be required. You can then be sure of receiving specific answers to each individual query. You will also then have a record of these communications and of all tutorial support, which has been provided to you. This makes tutorial support administration more productive by avoiding any unnecessary duplication, misunderstanding, or misinterpretation.
Tutorial Support Email Format
You should use this tutorial support format if you need to request clarification or assistance while studying with your training program. Please note that ALL of your tutorial support request emails should use the same format. You should therefore set up a standard email template, which you can then use as and when you need to. Emails that are forwarded to Appleton Greene, which do not use the following format, may be rejected and returned to you by the (CLP) Program Administration Manager. A detailed response will then be forwarded to you via email usually within 20 business days of receipt for general support queries and 30 business days for the evaluation and assessment of project studies. This does not include weekends or public holidays. Your tutorial support request, together with the corresponding TSU reply, will then be saved and stored within your electronic TSU file at Appleton Greene for future reference.
Subject line of your email
Please insert: Appleton Greene (CLP) Tutorial Support Request: (Your Full Name) (Date), within the subject line of your email.
Main body of your email
Please insert:
1. Appleton Greene Certified Learning Provider (CLP) Tutorial Support Request
2. Your Full Name
3. Date of TS request
4. Preferred email address
5. Backup email address
6. Course manual page name or number (reference)
7. Project study page name or number (reference)
Subject of enquiry
Please insert a maximum of 50 words (please be succinct)
Briefly outline the subject matter of your inquiry, or what your questions relate to.
Question 1
Maximum of 50 words (please be succinct)
Maximum of 50 words (please be succinct)
Question 3
Maximum of 50 words (please be succinct)
Question 4
Maximum of 50 words (please be succinct)
Question 5
Maximum of 50 words (please be succinct)
Please note that a maximum of 5 questions is permitted with each individual tutorial support request email.
Procedure
* List the questions that you want to ask first, then re-arrange them in order of priority. Make sure that you reference them, where necessary, to the course manuals or project studies.
* Make sure that you are specific about your questions and number them. Try to plan the content within your emails to make sure that it is relevant.
* Make sure that your tutorial support emails are set out correctly, using the Tutorial Support Email Format provided here.
* Save a copy of your email and incorporate the date sent after the subject title. Keep your tutorial support emails within the same file and in date order for easy reference.
* Allow up to 20 business days for a response to general tutorial support emails and up to 30 business days for the evaluation and assessment of project studies, because detailed individual responses will be made in all cases and tutorial support emails are answered strictly within the order in which they are received.
* Emails can and do get lost. So if you have not received a reply within the appropriate time, forward another copy or a reminder to the tutorial support unit to be sure that it has been received but do not forward reminders unless the appropriate time has elapsed.
* When you receive a reply, save it immediately featuring the date of receipt after the subject heading for easy reference. In most cases the tutorial support unit replies to your questions individually, so you will have a record of the questions that you asked as well as the answers offered. With project studies however, separate emails are usually forwarded by the tutorial support unit, so do keep a record of your own original emails as well.
* Remember to be positive and friendly in your emails. You are dealing with real people who will respond to the same things that you respond to.
* Try not to repeat questions that have already been asked in previous emails. If this happens the tutorial support unit will probably just refer you to the appropriate answers that have already been provided within previous emails.
* If you lose your tutorial support email records you can write to Appleton Greene to receive a copy of your tutorial support file, but a separate administration charge may be levied for this service.
How To Study
Your Certified Learning Provider (CLP) and Accredited Consultant can help you to plan a task list for getting started so that you can be clear about your direction and your priorities in relation to your training program. It is also a good way to introduce yourself to the tutorial support team.
Planning your study environment
Your study conditions are of great importance and will have a direct effect on how much you enjoy your training program. Consider how much space you will have, whether it is comfortable and private and whether you are likely to be disturbed. The study tools and facilities at your disposal are also important to the success of your distance-learning experience. Your tutorial support unit can help with useful tips and guidance, regardless of your starting position. It is important to get this right before you start working on your training program.
Planning your program objectives
It is important that you have a clear list of study objectives, in order of priority, before you start working on your training program. Your tutorial support unit can offer assistance here to ensure that your study objectives have been afforded due consideration and priority.
Planning how and when to study
Distance-learners are freed from the necessity of attending regular classes, since they can study in their own way, at their own pace and for their own purposes. This approach is designed to let you study efficiently away from the traditional classroom environment. It is important however, that you plan how and when to study, so that you are making the most of your natural attributes, strengths and opportunities. Your tutorial support unit can offer assistance and useful tips to ensure that you are playing to your strengths.
Planning your study tasks
You should have a clear understanding of the study tasks that you should be undertaking and the priority associated with each task. These tasks should also be integrated with your program objectives. The distance learning guide and the guide to tutorial support for students should help you here, but if you need any clarification or assistance, please contact your tutorial support unit.
Planning your time
You will need to allocate specific times during your calendar when you intend to study if you are to have a realistic chance of completing your program on time. You are responsible for planning and managing your own study time, so it is important that you are successful with this. Your tutorial support unit can help you with this if your time plan is not working.
Keeping in touch
Consistency is the key here. If you communicate too frequently in short bursts, or too infrequently with no pattern, then your management ability with your studies will be questioned, both by you and by your tutorial support unit. It is obvious when a student is in control and when one is not and this will depend how able you are at sticking with your study plan. Inconsistency invariably leads to in-completion.
Charting your progress
Your tutorial support team can help you to chart your own study progress. Refer to your distance learning guide for further details.
Making it work
To succeed, all that you will need to do is apply yourself to undertaking your training program and interpreting it correctly. Success or failure lies in your hands and your hands alone, so be sure that you have a strategy for making it work. Your Certified Learning Provider (CLP) and Accredited Consultant can guide you through the process of program planning, development and implementation.
Reading methods
Interpretation is often unique to the individual but it can be improved and even quantified by implementing consistent interpretation methods. Interpretation can be affected by outside interference such as family members, TV, or the Internet, or simply by other thoughts which are demanding priority in our minds. One thing that can improve our productivity is using recognized reading methods. This helps us to focus and to be more structured when reading information for reasons of importance, rather than relaxation.
Speed reading
When reading through course manuals for the first time, subconsciously set your reading speed to be just fast enough that you cannot dwell on individual words or tables. With practice, you should be able to read an A4 sheet of paper in one minute. You will not achieve much in the way of a detailed understanding, but your brain will retain a useful overview. This overview will be important later on and will enable you to keep individual issues in perspective with a more generic picture because speed reading appeals to the memory part of the brain. Do not worry about what you do or do not remember at this stage.
Content reading
Once you have speed read everything, you can then start work in earnest. You now need to read a particular section of your course manual thoroughly, by making detailed notes while you read. This process is called Content Reading and it will help to consolidate your understanding and interpretation of the information that has been provided.
Making structured notes on the course manuals
When you are content reading, you should be making detailed notes, which are both structured and informative. Make these notes in a MS Word document on your computer, because you can then amend and update these as and when you deem it to be necessary. List your notes under three headings: 1. Interpretation – 2. Questions – 3. Tasks. The purpose of the 1st section is to clarify your interpretation by writing it down. The purpose of the 2nd section is to list any questions that the issue raises for you. The purpose of the 3rd section is to list any tasks that you should undertake as a result. Anyone who has graduated with a business-related degree should already be familiar with this process.
Organizing structured notes separately
You should then transfer your notes to a separate study notebook, preferably one that enables easy referencing, such as a MS Word Document, a MS Excel Spreadsheet, a MS Access Database, or a personal organizer on your cell phone. Transferring your notes allows you to have the opportunity of cross-checking and verifying them, which assists considerably with understanding and interpretation. You will also find that the better you are at doing this, the more chance you will have of ensuring that you achieve your study objectives.
Question your understanding
Do challenge your understanding. Explain things to yourself in your own words by writing things down.
Clarifying your understanding
If you are at all unsure, forward an email to your tutorial support unit and they will help to clarify your understanding.
Question your interpretation
Do challenge your interpretation. Qualify your interpretation by writing it down.
Clarifying your interpretation
If you are at all unsure, forward an email to your tutorial support unit and they will help to clarify your interpretation.
Qualification Requirements
The student will need to successfully complete the project study and all of the exercises relating to the Leading IT Transformation corporate training program, achieving a pass with merit or distinction in each case, in order to qualify as an Accredited Leading IT Transformation Specialist (ALITTS). All monthly workshops need to be tried and tested within your company. These project studies can be completed in your own time and at your own pace and in the comfort of your own home or office. There are no formal examinations, assessment is based upon the successful completion of the project studies. They are called project studies because, unlike case studies, these projects are not theoretical, they incorporate real program processes that need to be properly researched and developed. The project studies assist us in measuring your understanding and interpretation of the training program and enable us to assess qualification merits. All of the project studies are based entirely upon the content within the training program and they enable you to integrate what you have learnt into your corporate training practice.
Leading IT Transformation – Grading Contribution
Project Study – Grading Contribution
Customer Service – 10%
E-business – 05%
Finance – 10%
Globalization – 10%
Human Resources – 10%
Information Technology – 10%
Legal – 05%
Management – 10%
Marketing – 10%
Production – 10%
Education – 05%
Logistics – 05%
TOTAL GRADING – 100%
Qualification grades
A mark of 90% = Pass with Distinction.
A mark of 75% = Pass with Merit.
A mark of less than 75% = Fail.
If you fail to achieve a mark of 75% with a project study, you will receive detailed feedback from the Certified Learning Provider (CLP) and/or Accredited Consultant, together with a list of tasks which you will need to complete, in order to ensure that your project study meets with the minimum quality standard that is required by Appleton Greene. You can then re-submit your project study for further evaluation and assessment. Indeed you can re-submit as many drafts of your project studies as you need to, until such a time as they eventually meet with the required standard by Appleton Greene, so you need not worry about this, it is all part of the learning process.
When marking project studies, Appleton Greene is looking for sufficient evidence of the following:
Pass with merit
A satisfactory level of program understanding
A satisfactory level of program interpretation
A satisfactory level of project study content presentation
A satisfactory level of Unique Program Proposition (UPP) quality
A satisfactory level of the practical integration of academic theory
Pass with distinction
An exceptional level of program understanding
An exceptional level of program interpretation
An exceptional level of project study content presentation
An exceptional level of Unique Program Proposition (UPP) quality
An exceptional level of the practical integration of academic theory
Preliminary Analysis
Online Article
“An Agile Approach to Digital Transformation (+Principles, Benefits)
By Priyanka Malik,
June 2, 2022,
WhatFix.com
In 2018, 70-years-old Toys ‘R’ Us closed its doors for good. Children were beginning to play online games while the shopping experience had moved online. Toys ‘R’ Us, lacking the agility to cross over to the digital world, allied itself with a startup called Amazon which led to the toy store’s collapse.
Legacy companies need the technical skills to make the leap, the budget to purchase new technologies, qualified servant leadership to transform themselves, a workforce that blends skills with technological knowledge, and the know-how to overcome resistance to change. Most of all they have to adopt the right system that helps them effectuate that change.
That’s where the agile approach comes in, with major industry leaders like General Electric (GE), Netflix, and Nestle testifying how agile has helped them digitally transform their businesses.
What is Digital Transformation?
Modern companies have a choice: digitize yourselves or go extinct. Digital transformation is the process of upgrading legacy systems and manual processes to digital ones, to meet evolving customer expectations, automate tasks, and drive productivity.
Consumers seek innovation. They want shopping experiences that are fast and convenient. Research shows brands with strong omnichannel customer engagement strategies retain around 89% of their customers, in contrast to 33% of companies with weak strategies. It’s all about being digitized which means adopting digital innovations like virtual assistants, robots, drones, AI, or augmented shopping experiences (and so forth) as consumers seek the comfort, excitement and instant gratification that comes with digital service.
Tools include customer relationship management (CRM) software for retaining and attracting customers. If you’re a financial institution or large healthcare company you’ll want machine learning systems that help you collate, secure, analyze, distribute and automate your Big Data in real-time to compete. For retailers, it’s plugging into an e-commerce platform that helps your company stay relevant as you scale across both physical and digital landscapes.
Most businesses have a robust social media presence. On top of that, you need cybersecurity solutions to protect you and your client from being infiltrated by malicious actors.
It’s a race. Those that implement new technology as well as optimize their legacy systems win.
Unfortunately, it’s not easy. You need the right digital transformation strategy to guide you. That’s where agile comes in.
What is Agile Transformation?
Agile is a test-and-learn process with the system divided into sprints, or phases, of one to three weeks, with each sprint containing its own goal. Responsibility for the project is shared by the whole team who collaboratively decide when to move on to the next phase.
The 12 principles of Agile prioritize iterative and incremental development, collaboration and self-organizing, cross-functional teams and quality over rules. Most of all Agile is a steady iterative process of “growing into it’’ that takes time, where the team learns from mistakes and automates improvements.
The four core values of the Agile methodology are:
• Individuals and interactions are superior to the following protocol.
• That software works is more important than extensive documentation on how it should work.
• Customer collaboration and satisfaction are more important than contracts.
• Responding to change is what matters rather than following a plan. Agile is dynamic, flexible, and an ongoing learning process.
Done well, research indicates that businesses that adopt the agile methodology experience 98% rate of success and 60% more profit than companies that lean towards the traditional approach. More than three-thirds of marketing leaders told leading agile marketing and consulting organization, Agile Sherpas, that they became significantly more productive after embracing the Agile approach.
For these reasons among others, at least 95% of organizations practice Agile development methods according to the most recent 15th Annual State Of Agile Report.
Framework for Agile Transformation
The actual framework iterates around these three procedures:
1. Collaboration activities: Stakeholders organize daily stand-up meetings, and scheduled sessions, such as milestone reviews, backlog refinement sessions, and project update meetings. In short, it’s where team members (and sometimes users and external agents) meet to discuss product performance and discuss how to proceed.
2. Reviews: The development team demonstrates its finished work and answers questions, following which the Product Owner (or team as a whole) discusses the work backlog or work in process. Potential deadlines for the next segment are discussed as are other considerations such as possible changes in items like timeline, budget, or marketplace demands.
3. Retrospective: The Team sits for two to three hours to discuss the results of the review session and to reflect on what they should (a) stop doing (b) start doing c) keep doing. Retrospective helps the stakeholders plan the next iteration and promotes continuous improvement.
What Is Agile Digital Transformation?
Agile Digital transformation is simply where legacy companies follow the Agile approach to successfully develop the capacities for delivering innovation.
The biggest challenges of digital transformation include coming to grips with complex software and technology, learning new tools and processes, negotiating security concerns, dealing with budget restraints, navigating resistance to change, and adapting technology to customers’ changing needs. Most of all, there’s the need for a simple but effective change management strategy.
Agile provides the perfect solution with its iterative time-boxed approach which helps teams practice their new skills. Agile is open to failure, encouraging legacy companies to improve their skills. It’s customer-centric, including clients in its deliberations therefore more likely to please them. The team moves on only after all security concerns have been resolved.
Most of all, the agile approach provides the perfect risk-free solution in that it splinters digital transformation into short manageable phases, where the team learns from their results before moving on. Less money is invested since mistakes are fewer and projects usually end up delivering value to users.
In short, the agile approach to digital transformation is:
• Adaptive in contrast to following a plan
• Self-managed in that it’s controlled by the team at all levels in contrast to manifesting top-down executive control
• Periodically assessed and reviewed by the team in contrast to undergoing metric evaluation
• Evaluated on whether or not it satisfies the end-user. That’s in contrast to companies that build their digital infrastructures under inflexible, highly mechanized and standardized procedures.
All of this makes agile digital transformation nimble, flexible, dexterous and fast.
Best Practices for an Agile Approach to Digital Transformation
A few things to keep in mind when adopting an agile approach to digital transformation include:
• Identify the purpose of your business transformation. Know your value proposition
• Include Security Champions in your team, so security remains one of your topmost concerns.
• Stimulate proactive cross-department collaboration, seeking input not just from IT but from inter-and intra-department experts and from external stakeholders too.
• Encourage stakeholders to share their anxieties and concerns.
• Consider introducing the Prosci ADKAR Model to help employees overcome their probable fears of digitalization and/ or of losing their jobs.
Challenges of Agile Digital Transformation
That said, a boggling 47% of agile-pioneered transformations fail. Reasons include:
1. Employees fear technology will replace their jobs
2. There’s no clear value proposition – stakeholders are vague on why they need that innovation.
3. Lack of funds to purchase new technologies
4. Absence of qualified leadership to drive transformation initiatives
5. There’s a shortage of resources with the right combination of skills and industry knowledge
6. Certain units or departments of the organization may hesitate to welcome transformation
7. Work can lapse into chaos since it lacks the centralizing directing force.
8. Negative feedback from as few as two or three members could lead to endless product cycle loops.
Above all, there’s the organization’s failure in selecting an effective change management strategy to manage organizational change.”
If you would like to continue reading this article, please visit: www.whatfix.com
Online Article
“Digital Transformation Success Depends on Agile Approach to Change
By Peter Bendor-Samuel,
Aug 26, 2019,
Forbes.com
The principles and practices of the agile movement are quickly moving beyond the IT department and into how firms run their day-to-day business. This new way of organizing and running business gains further impetus by the headlong rush to use digital transformation to gain competitive advantage, which often requires changing a company’s operating model through many iterative steps known as a journey. Using the agile approach, they minimize risks and can validate that their efforts are meeting the desired outcome as they move forward on their journey. Unfortunately, many companies see these benefits of an agile approach, but they struggle to do that. What are they missing?
A key element that many firms miss is the necessity to change their corporate culture to support an agile environment. At the heart of this cultural change is the long-standing practice of penalizing failure. In traditional organizations, executives and managers are not allowed to fail. They are given targets, held accountable to those targets, and failure is not tolerated. This understanding is deeply ingrained in business psyche.
In an agile environment, we hear a lot of talk about failing fast and failing forward; however, organizations don’t allow failure in projects. True digital transformation can only be accomplished in an agile framework, so experimentation must be allowed.
One of the keys to navigating through the unknowns of the deep change that most digital transformation demands is the willingness to experiment to learn and test. Failures – doing things and finding they don’t work or don’t work as well as we had anticipated – is part of how we move into the unknown, and much of the details of a transformation journey are unknown and evolve on the journey. Failure, or at least some level of dissatisfaction with results, is often the norm.
The Danger Of Not Taking An Agile Approach
With the ambiguity of big business model change at the heart of most ambitious digital transformation efforts, the organization must build a foundation of learning to build the conviction that the change is worth the effort and that it will lead to the needed results. This foundation can only be built through an ongoing series of experiments that must risk failure to absorb the learnings.
Here’s an ironic fact – in companies with a culture focused on meeting objectives and never failing, executive often proclaim these experiments and pilots as victories even when the actual results were not a success. In effect, the organization lies to itself and builds its confidence and learnings on false facts and experiences. Often, executives question these assumptions, but they are intimidated or ignored. Once momentum builds behind well-funded projects that are backed by senior executives, it becomes politically untenable to be seen questioning or resisting them. The transformation initiatives then move forward on flawed foundations and incorrect learnings.
Consequently, companies build their digital transformation on a foundation of lies and overrepresentations or misrepresentations. This is particularly troubling in digital transformation, where companies need tightly coupled components that could interact with each other seamlessly toward a great customer or employee experience.
Here’s a common example. Executives make promises are made, they conduct evaluations, undertake pilots, prepare specifications and spend millions of dollars promising initiatives that will be incorporated into programs. But often the organization exhausts itself on the effort and never achieves most if any of the promised objectives of the program. At every step of this process, the organization lies to itself about the success of the previous stages. By exaggerating their success or failing to create the learnings from their failures, they then move forward with flaws tightly integrated into their transformation, building an ever-compounding problem.
How To Resolve The Problem Of Not Having An Agile Environment
Resolving the issue and truly embracing the agile philosophy for transformation requires a mindset change from companies’ traditional view of failure not being allowed. Experimentation is an essential element. Companies need to celebrate the fact that they fail, that they do things to learn and test, rather than penalize failure.
Experimentation implies that not all activities will, in fact, release their intended value. In failing fast and failing forward, companies can do projects, understand whether they succeed or don’t succeed and then do another initiative to address the gaps. Because the transformation journey is broken down into short sprints, companies can quickly recognize when value isn’t being achieved or the business objectives are not being achieved and then adapt quickly to address those issues. The program is not allowed to change, but companies can objectively assess the impact of individual projects and recognize where those projects fail against their objectives.
We may need to change the corporate lexicon. We need to rename the term “failure” to something like “pilot to learnings,” rather than “failure.” Otherwise, it’s easy to confuse pilot or project failure with program failure. Clearly, companies cannot tolerate program failure. But if they can’t be brutally objective and honest about the success and learnings of the individual components, then they are doomed to build fatal flaws into their digital transformations.
The traditional approach and mindset are a waterfall type of process. Companies come up with a vision, build a business case for the vision, fund the business case and then work on a detailed two-year or 18-month plan to implement it. This approach has a very high proportion of transformation failures. In fact, it works against agile philosophies and processes.
The agile approach to transformation is a very different world than big, major projects with managers holding teams accountable for delivery of predefined workstreams. In the agile approach, the company sets the goal but not the time or cost. Breaking the journey down into sprints or phases with goals for each sprint allows adjusting to get to the desired impact. Each goal aims to prove the viability of the change coming about because of the transformation.
Moreover, an agile, iterative structure – experimentation – for the journey enables identifying where new business value can be created and ways to delivery new value. That’s a success, not a failure!”
If you would like to view the original article, please visit: www.forbes.com
Online Article
“Digital Transformation Powered by Agile Methodologies
By Julia Adler,
OPIN.com
The cornerstone of business success in the digital world is the ability to adapt. For an organization to thrive in a fast-paced world, they must be able to respond to new opportunities and threats quickly to come out stronger on the other side. Around the world, more and more organizations are embracing agile methodologies. During the COVID-19 pandemic, many organizations have accelerated their shift to agile with the hopes of speeding up project delivery and enhancing customer experience.
For digital businesses, agile methodology is a compelling approach for a business that wants to succeed in the face of fierce competition and escalating customer expectations. Modern businesses use digital transformation as a tool for adaptation. Ongoing digital transformation enables an organization to stay at the forefront of technology trends and the cutting edge of user experience. Digital transformation is a relatively easy strategy to design, but the execution of the strategy is where many businesses run into barriers. This is where Agile comes into play.
Agile for digital transformation
Agile methodology is an iterative design process wherein requirements and solutions for a project constantly evolve. Cross-functional teams collaborate in “sprints” where a working concept is developed and shared with end-users. Feedback is then taken into consideration for the next sprint, and the cycle is repeated until the solution is finalized. The most important trait of agile development is that it encourages rapid and flexible response to change. This way, executives can first envision a strategy for digital transformation, then ensure it aligns with the realities of the business environment. Agile methodology enables organizations to derive relevant data and formulate adaptive plans for digital transformation. Agile methodology, when adopted, has the potential to promote flexibility, speed, and continuous improvement. An agile organization ultimately empowers its units to be more responsive to change and adapt to local customer needs, ensuring executive goals are met while retaining the ability to innovate and adapt.
Creating an agile environment
Agile is a way of thinking as much as it is a project management methodology. This means that businesses have to train themselves to think in the new mindset and employees must open themselves up to new ways of working. The methodology promotes adaptation and provides the business with the tools needed to achieve digital transformation. An organization that is agile needs to break down the business into units, capitalize on the skills of cross-functional teams and encourage collaboration. The responsibility of an agile team is to be flexible, focused and work around shorter planning cycles. A good IT leader should be a pillar of motivation to the team and encourage transparency especially when the team is working to achieve an objective.
Benefitting from an agile culture
An organization that is agile orients itself to customer needs and is able to optimize customer experience on an ongoing basis. The backbone of an agile organization is the right technology ecosystem with access to the right data. This allows you to create a testing and learning environment where prototypes can be optimized. Using sprints, the organization can take advantage of this environment to continually adapt their products and customer experience to the changing environment.
Agile Barriers
Despite the growing popularity of agile methodology, few organizations are implementing the process. About 36% of organizations report implementing a singular framework across teams with minimum management support and experience in agile methodology. The largest barrier to digital transformation in organizations is a culture where change is not encouraged.
Agile methods act as a catalyst for innovation, but accepting and implementing these methods within an organization takes time. As digitization progresses, businesses need to respond quickly to changing market demands and develop new business models. The technology exists, yet product innovations and projects often continue to fail because companies are structured with too much rigidity, suppressing creativity and innovation. Which is why companies should focus on agile methods to drive innovation.
Agile Values Explained:
At this point you may be wondering a bit more about the specifics of agile, so here is a short history lesson about agile and how these methods came to be. 17 methodologists defined a manifesto that encouraged better and more reliable ways to develop software. Based on this manifesto, a collection of values that define the criteria to be employed in agile software development processes was formulated. The four values defined in the manifesto formed the foundation of the agile movement. They define preferences rather than alternatives and encourage a focus on particular areas without eliminating others. The following are the values of the Agile Manifesto:
1. Individuals and interactions rather than processes and tools
Software systems are created by teams of people and in order to make a project successful, effective participation is mandatory for each team member. This includes, but is not limited to, the customers, modellers, project managers, testers and programmers. This value places more emphasis on people and how they are able to work together. If this is not a primary factor of consideration, even the best tools and processes will not be of any use. As much as tools and processes are important, they can’t yield the same results as working together effectively.
2. Working software rather than comprehensive documentation
It makes more sense to work in a manner through which you are able to produce software much faster and are able to meet the needs of users. Users will most definitely have an easier time understanding the software you come up with than the complex diagrams that describe its internal functionality or abstractions of its usage. Documentation is an invaluable guide that helps people understand the reasons behind the creation of software and its functionality. Nevertheless, the primary goal of software development is creating software and not documents.
3. Customer collaboration rather than contract negotiations
Only your customers can tell you what they need. They may not be equipped with the skills that can exactly specify the system and most likely, they won’t get it right the first time. It’s often hard to work together with your customer but it tends to build the foundation for better relations. Yes, you need to have a contract with your customer but of greater importance is to understand that everyone has their rights and responsibilities. This helps to formulate a contract, although the contract is not meant to be a substitute for effective communication. Working closely with customers is essential for every developer; you need to invest as much effort as possible to discover the needs of your customers and educate them along the way.
4. Responding to change rather than following a plan
Everyone is bound to change their priorities. This happens for several reasons. As the work progresses on systems, the understanding of project stakeholders on the problems being faced and the software being developed changes. This is also the case with the business environment and technology, but not always for the better. Change is inevitable and applies to software development of the same magnitude. This should be reflected in the process. It is also important to understand that there’s actually nothing wrong with using a project plan. As a matter of fact, every project needs one. However, this project plan should be malleable and allow room for change since situations change that might render the plan irrelevant.
These value statements were created to ensure better practices in the field of agile software development without isolating any member of the team. In each one of them, there’s something almost everyone instantly agrees to and all participants admitted that the creation of software is the primary goal of software development.
Digital transformation is a continuous process and business leaders are tasked with the challenge of embracing it in order to drive change from the top down. Implementing agile methodology is necessary, not only as a project framework but as a culture shift within the organization.
The roots of agile methods lie in software development. Since software is the basis for all digital business models, agile methods are gaining increased acceptance. In addition, rapid technological change is forcing CIOs to rethink their digital transformation strategies. Agile methodology is no longer used only in IT. In a survey by the certification organization Scrum Alliance, more than half of those surveyed stated that other areas of the company use agile methods.
Innovation, speed and team productivity
An analysis of more than 10 000 projects revealed that the use of agile methods more than triples the probability of success. Many companies have recognized that the challenges of digitization require an agile environment to stay ahead of changing trends. However, employees tend to have difficulty transferring newly acquired knowledge into their organizations. Why is that? Companies often have a vertical, hierarchical culture that has existed for many years, which prevents rapid innovation. In many cases, agile contradicts the existing corporate culture.
Adapting with agile
Adapting to agile doesn’t mean completely restructuring an organization in one day. If you want to accelerate processes and make teams more innovative, you can first test agile methods in suitable projects. This helps to reduce prejudices and to slowly anchor ‘agile’ in the minds of your employees. The most important thing to remember? Involving your own employees, equipping them with the necessary knowledge for modern work and sharpening their understanding of agile work processes and team leadership. If you know more and understand more, you will be able to tackle projects in new ways.”
If you would like to view the original article, please visit: www.opin.ca
Course Manuals 1-10
Course Manual 1: Agile Challenges
47% of Agile transformations fail, and 67% of these failures are fatal, according to Jeff Sutherland, a co-creator of Scrum.
Given that more than half of all firms are currently utilizing Agile to drive their transformations, that astounding number is astounding.
What leads to the failure of an enterprise-wide transformation? Why is it so difficult to apply what has been successful at the team level to the entire organization?
Success is fueled by transformation and change. The old saying “The only thing constant is change” is true, and companies and cultures must adapt as people do. This became abundantly clear during the COVID-19 epidemic, during which the entire working paradigm experienced a radical shift.
Organizations must act quickly and produce more in these turbulent conditions if they want to remain relevant. And the only way to accomplish this is by updating the outdated legacy systems and implementing procedures that permit:
• increased efficiency,
• shorter time-to-market,
• improved quality,
• happier customers,
• faster ROI, and
• satisfied employees.
When properly executed, agile transformations can contribute to all these advantages. Business agility integrates responsiveness and adaptability into an organization’s very foundation, and its effects are felt at every level of the company.
However, as the numbers demonstrate, firms frequently embark on an ambitious full-scale transformation only to discover midway through that it is not succeeding.
Failure of a large-scale agile transition can occur for a number of reasons:
• Lack of leadership support
• Lack of commitment at every level of the organization
• Incorrect application of popular agile methodologies
• A lack of understanding of which methodology will suit your organization
• Rushing the transformation process.
Understanding the agile business model, which consists of four domains, is the first step in experiencing an Agile transformation. In order for agility to be embraced, these 4 domains specify how and what needs to change.
These are the 4 domains:
1. Business domain: Encompasses how an organization works, what it prioritizes, how it budgets, products it focuses on and more.
2. Organizational domain: Relates to how the organization is structured. Too many departments and too many teams can make agile transformation a nightmare if done incorrectly.
3. Cultural domain: Every organization has a culture, a mind-set which may or may not be difficult to change. But helping the organization and the staff make this mind-set change is the most crucial step towards bringing in a transformation. Whether autonomy is allowed in teams or if there is a strict top-down approach; these are aspects that need to be carefully examined.
4. Technical domain: This relates to the technical expertise of individual teams, their work ethics and their degree of self-independence. Self-organized teams work better, and are more responsive and successful.
Challenges of an Agile transformation
• Your organizational culture blocks change: A company’s core culture impacts not just how it does business but also how it treats its employees. Better engagement, more appreciation, transparent communication, empowering employees and teams, open processes are all hallmarks of an agile culture.
An organization that is rigid, has tightly controlled processes, does not value human resources and has not yet fully embraced the idea of change is a sitting duck for transformation failure.
• Transformation at scale: It’s okay to start small, maybe at the team level or a department level, but change has to be brought about in the entire organization. Just having one or two teams that are agile is not going to help you in your transformation.
To ensure business agility, the entire organization must adopt agile methods. If the agile methodology is not pursued beyond the trial stage, its effect will be constrained.
• Leaders are not convinced: For any change or transformation to be successful, the leaders must be convinced of the change. A transformation across the organization is impossible without the support of the management.
Agile leaders lead the transformation from the front, bring in the necessary investments, aid in creating a culture that fosters innovation and create a platform for open communication among all employees.
• Rushing the transformation: Rome was not built in a day! An organization that rushes its transformation process does so without proper planning, knowledge of processes or the support it requires to carry out this gargantuan task.
A successful transformation takes several years and focuses on everything from culture change to process change to mind-set change. A rushed effort will reveal gaping holes in the transformation foundation and will surely lead to the effort coming tumbling down.
• Not helping employees’ transition: Your workforce is your company! A successful transition means helping the workforce understand:
– the agile process
– the skills that would be required in the new process
– how they will be supported in new roles
– how their career paths may change due to agile transition
Agile adoption requires a flexible workforce, and management must be upfront and honest with its staff about the entire process. Employee attrition and skill loss might result from a lack of transparency.
What to do for a successful transformation?
1. Get leadership buy-in: Successful agile leaders support culture change. According to Scrum.org, Agile leaders focus on 3 things:
• They create and nurture a culture in which experimentation and learning are embraced;
• They collaborate with employees (at all levels in the organization) to find common values to create a greater goal for the company and the teams; and
• They create an organizational structure that reinforces and rewards the other two dimensions.
2. Strategize: There has to be a strategy on how, what and why to implement. Large, complex organizations cannot go agile overnight. They have to create an agile roadmap, bring together people, processes and technologies and implement agile at the right places to test its efficacy before scaling.
3. Hand-hold employees of all levels: So how do you keep your employees informed and empowered through the transformation? Since agile means a change in processes it also requires a change in the way people are managed.
Agile trainings, presentations, and learning opportunities must be used to guide employees through the transformation. Reiterating the ideas will help teams comprehend them and feel comfortable working in a novel setting.
Particularly agile coaching and training are excellent tools for helping staff members adopt the agile way of thinking.
4. Understand that agile is mostly about an organizational culture transformation:
An agile-friendly culture is necessary for a successful agile transformation. It may be challenging for large firms that have used the conventional method to accept new working practices. It’s not impossible, though. The only way to change a culture is if everyone is on board.
A change in organizational culture is required in addition to leadership alignment. In order to bring about this transition, it is crucial to have both a top-down and a bottom-up strategy, and this can be achieved by being open and sincere in your communication about the changes that your leaders intend to implement.
You have an agile-ready culture if you:
• Listen to your customer
• Make real-time decisions instead of relying on reports
• Take risks and learn from failures
• Rely on cross-functional and self-organized teams
• Have transparent and approachable leadership
• Have top-down, bottom-up and cross-communication across the organization
To conclude: Organizations must learn from their mistakes and be flexible in order to successfully implement Agile.
Unprecedented obstacles will be faced by organizations as they undergo an agile transformation. The secret is to embrace change and learn from your failures. A skilled agile partner who can coach staff members and the organization through training and change management efforts is also necessary for the agile transition.
7 Testing Challenges in Agile and How to Master Them
Continual agile development techniques present several significant testing challenges:
1. Changing Requirements
Even though it is not recommended in an agile/Scrum framework, it might occasionally happen that management modifies requirements or drops stories during a sprint. As a result, work that has already begun must be abandoned or amended, which suddenly alters the testing’s scope.
How to master:
Because change is a constant in agile projects, testers should be ready to respond quickly and adjust their procedures as necessary. When requirements change, testers should communicate as much as possible about the tests they’ve performed and the parts of the application that haven’t yet been tested. This can assist the team in figuring out how to modify the sprint as needed without compromising the quality of the final product.
2. Not Enough Information
Product owners, who are in charge of creating user stories, could be aware of the general idea behind a new product but not its particular. As a result, they are unable to create a solid set of acceptance criteria. Testers are unable to create thorough test cases if there is a lack of information regarding the requirements.
How to master:
Testers can start by creating high level scenarios that verify the notion of the story without needing detailed requirements; they can then check these scenarios with the product owner. Testing can be carried out without having access to all of a feature’s specifics. Even when specifics change, high level test scenarios can still be created.
3. Continuous Testing
Testing is a continuous process that begins prior to the development phase rather than being limited to a single stage. Because testers are expected to begin developing tests for features either before development even begins or in the middle of it, this poses a significant challenge.
How to master:
User stories in the queue should be expanded during sprint planning to make life simpler for testers. Together, testers, developers, and product owners should determine each story’s specifics before creating effective acceptance criteria.
Before beginning work on development, the team should make sure that each narrative has enough acceptance criteria and that everyone understands the story’s context. As a result, it is easy to start developing tests as soon as the feature’s code is complete and then put them into use.
4. Technical Skills
In order to assist developers with API testing, integration testing, and scripting UI automation checks with Selenium or comparable frameworks, testers working in an agile setting need to be technically astute. Agile testing has a high learning curve for testers with experience in exploratory or manual testing.
How to master:
Testing professionals can and should learn scripting and programming languages like Javascript and Ruby. Testers who are proficient in programming but have little hands-on expertise can seek assistance from developers. Additionally, testers can master automated testing software like JMeter and the Selenium tool.
Teams should have dedicated testers with the necessary professional backgrounds for specialized testing areas like performance, security, or compliance testing, or they should use consultants with extensive experience in these fields.
5. Frequent Regression Cycles
The product’s features are continually and regularly added by developers. Previous features may experience regressions as a result. Regression testing is used by testers to find and fix this issue, but manual regression testing is unfeasible in a quick-paced agile environment.
Modern web apps behave differently when accessed on various devices or browsers, which presents another difficulty. As a result, there is a complicated matrix of compatibility testing scenarios that must be checked to make sure the program works properly for all users.
How to master:
Robotic testing is used by agile testers. They evaluate the code using unit tests to make sure that recent modifications did not break it, and they check for functional regressions using tools like Selenium and JMeter. To manage and run their automated tests simultaneously across many browsers and PCs, testers can utilize Docker or Selenium Grid.
6. Lack of Communication
Agile testing will not function if developers, testers, and product owners are not in constant communication.
How to master:
Direct contact should be highly promoted inside the team. To make sure everyone is on the same page, developers, testers, and product owners should meet in person frequently. Common understanding of the sprint’s scope and objectives is achieved through the use of Scrum ceremonies including stand-up meetings, sprint planning, and retrospectives.
7. No Quality Measurement
Currently, there isn’t a single quality indicator that agile teams may use to direct and coordinate their testing efforts.
None of the metrics, including unit test code coverage, lines of code (LOC), and code complexity, gives a clear picture of “where we stand” with quality at each stage of a sprint or release, indicating which parts of the product are stable and less likely to experience quality problems.
Most agile teams are unable to focus proactively on the product areas that have the most serious quality issues, instead reacting to production errors or defects.
Business Agility Example: 4 Companies Who Weren’t Agile and What We Can Learn
BLOCKBUSTER
Do you still recall entering a Blockbuster on a Friday night? Pushing through the double doors, cramming your three rentals from the previous weekend into the tiny return slot, and hurriedly navigating rows of concession stands and merchandise to get to the new releases section where you peruse a few trending titles while silently hoping they still have at least one copy available.
The truth was that rents hardly ever generated any cash flow. At its foundation, Blockbuster’s business strategy relied on late fees as its primary source of income. In other words, the capacity to charge customers for late returns was crucial to its success. This implied that while renting movies could be enjoyable, it would have to be anything but convenient.
THE TURNING POINT
Netflix served as the canary in the mine for Blockbuster. Netflix demonstrated that there were other options, although the majority of Blockbuster’s conventional rivals still used the same storefront renting model.
Instead than focusing on charges and margins, Netflix began to gain significant market share by emphasizing cost and convenience. Of course, the influx of competing services like Redbox was the hammer that finally sealed the deal.
Years ago, Netflix CEO Reed Hastings approached Blockbuster with the idea of a video streaming service, only to be laughed out of the room. This was a true kick in the face. Ten years later, streaming services were a commonplace, with Netflix today having an audience of more than 200 million. Now who is laughing?
Course Manual 2: Extreme Programming (XP)
One of the several Agile frameworks used by IT firms is Extreme Programming (XP). But what sets XP apart from other methods is the focus it places on technical aspects of software development.
With the intention of developing techniques to swiftly write high-quality software and be able to adapt to clients’ shifting requirements, software engineer Ken Beck introduced XP in the 1990s. He improved XP methods in the book Extreme Programming Explained: Embrace Change, published in 1999.
A collection of engineering practices is known as XP. While implementing these techniques, developers must go above and beyond their skills. The word “extreme” in the framework’s name refers to this. We’ll begin by outlining the lifecycle of XP and the many roles involved so that you may gain a better knowledge of these techniques.
The process and roles of extreme programming
The XP framework typically entails five iterative steps or stages of the development process:
1. Planning, the first stage, is when the customer meets the development team and presents the requirements in the form of user stories to describe the desired result. The team then estimates the stories and creates a release plan broken down into iterations needed to cover the required functionality part after part. If one or more of the stories can’t be estimated, so-called spikes can be introduced which means that further research is needed.
2. Designing is actually a part of the planning process, but can be set apart to emphasize its importance. It’s related to one of the main XP values that we’ll discuss below — simplicity. A good design brings logic and structure to the system and allows to avoid unnecessary complexities and redundancies.
3. Coding is the phase during which the actual code is created by implementing specific XP practices such as coding standards, pair programming, continuous integration, and collective code ownership (the entire list is described below).
4. Testing is the core of extreme programming. It is the regular activity that involves both unit tests (automated testing to determine if the developed feature works properly) and acceptance tests (customer testing to verify that the overall system is created according to the initial requirements).
5. Listening is all about constant communication and feedback. The customers and project managers are involved to describe the business logic and value that is expected.
XP lifecycle in a nutshell
A procedure like this requires collaboration between a number of individuals, each of whom has specific duties to fulfill. Extreme programming puts the user at the heart of the system, highlighting the value and significance of interpersonal abilities including cooperation, communication, and responsiveness. Consequently, following roles are frequently linked to XP:
1. Customers are expected to be heavily engaged in the development process by creating user stories, providing continuous feedback, and making all the necessary business decisions related to the project.
2. Programmers or developers are the team members that actually create the product. They are responsible for implementing user stories and conducting user tests (sometimes a separate Tester role is set apart). Since XP is usually associated with cross-functional teams, the skill set of such members can be different.
3. Trackers or managers link customers and developers. It’s not a required role and can be performed by one of the developers. These people organize the meetups, regulate discussions, and keep track of important progress KPIs.
4. Coaches can be included in the teams as mentors to help with understanding the XP practices. It’s usually an outside assistant or external consultant who is not involved in the development process, but has used XP before and so can help avoid mistakes.
Values and principles of extreme programming
Ken Beck described a collection of values and concepts that describe extreme programming in the late 1990s. These values and principles promote more effective teamwork and, ultimately, superior product quality.
Values and principles of XP
Values of extreme programming
To facilitate teamwork, XP has five simple guidelines that are based on these values:
1. Communication. Everyone on a team works jointly at every stage of the project.
2. Simplicity. Developers strive to write simple code bringing more value to a product, as it saves time and effort.
3. Feedback. Team members deliver software frequently, get feedback about it, and improve a product according to the new requirements.
4. Respect. Every person assigned to a project contributes to a common goal.
5. Courage. Programmers objectively evaluate their own results without making excuses and are always ready to respond to changes.
These principles describe a certain way of thinking among motivated team members who give their all in pursuit of a common objective.
These ideals serve as the foundation for XP principles, which represent them in more detailed ways.
Principles of extreme programming
Most academics refer to the five XP principles as:
1. Rapid feedback. Team members understand the given feedback and react to it right away.
2. Assumed simplicity. Developers need to focus on the job that is important at the moment and follow YAGNI (You Ain’t Gonna Need It) and DRY (Don’t Repeat Yourself) principles.
3. Incremental changes. Small changes made to a product step by step work better than big ones made at once.
4. Embracing change. If a client thinks a product needs to be changed, programmers should support this decision and plan how to implement new requirements.
5. Quality work. A team that works well, makes a valuable product and feels proud of it.
After going over the basic tenets and guiding concepts of XP, let’s examine the practices built into this framework in more detail.
Extreme programming practices
The XP practices are a set of particular guidelines and procedures that set it apart from other methodologies. When combined, they strengthen one another, aid in reducing development process risks, and produce the desired high-quality outcome. When creating software, XP advises following 12 practices that can be categorized into four areas.
XP main practices
Test-Driven Development
Is it feasible to fast write a clear code? The answer is indeed yes, according to XP experts. Software’s high quality is a result of its rapid development, which enables frequent feedback. Additionally, thorough testing yields useful feedback. The test-driven development technique (TDD), which requires building an automated unit test before the actual code, is used by XP teams. Every piece of code must pass the test in order to be released, according to this method. Software engineers concentrate on writing code that can perform the required function as a result. TDD enables programmers to leverage quick feedback to create dependable software in this manner. In our specialized article, we cover more information regarding enhancing software testing.
The Planning Game
This gathering takes place at the start of an iteration cycle. Together, the customer and the development team go over and approve a product’s features. Developers assign responsibilities for each upcoming iteration and release as they finalize their plans throughout the planning game.
On-site Customer
As we’ve already discussed, XP believes that the end user should be actively involved in the development process. The client should be present at all times to respond to team inquiries, establish priorities, and settle disagreements as needed.
Pair Programming
In order to use this technique, two programmers must collaborate on the same code. The second developer evaluates code, makes suggestions for enhancements, and resolves errors as they arise while the first developer concentrates on writing. Although it takes somewhat longer, such teamwork produces high-quality software and promotes knowledge exchange more quickly. In this sense, it makes more sense to experiment with pair programming for lengthy projects.
Code Refactoring
XP teams also employ refactoring to produce business value with well-designed software in each brief iteration. This method aims to make code better all the time. Refactoring aims to improve code coherence, eliminate redundant functions, reduce redundancy, and simultaneously decouple various components. Any member of the XP team will advise you to keep your code clear and straightforward so you can quickly comprehend it and adjust it when necessary.
Pair programming in XP iteration cycle, source: extremeprogramming.org
Continuous Integration
The system is always fully integrated by the developers. Because XP teams submit code several times per day—a practice also known as continuous delivery—they elevate iterative development to a new level. Practitioners of XP are aware of how crucial communication is. The elements of the code that can be reused or shared are discussed by programmers. They are then able to determine precisely what functionality they must create. The shared code policy aids in the eradication of integration issues. Automated testing additionally enables developers to find and correct mistakes before to launch.
Small Releases
This method recommends releasing the MVP as soon as possible and then iteratively improving the product moving forward. Small releases enable developers to get feedback regularly, find errors quickly, and keep an eye on how the product performs in the real world. The continuous integration process (CI) we previously stated is one way to achieve this.
Simple Design
The simplest software design that functions is the best. Any complexity should be eliminated if it is discovered. The ideal design should pass all tests, have the least amount of methods and classes, and no duplicate code. Additionally, it must accurately convey the programmer’s intention.
Practitioners of XP emphasize that after a product has been in production for a while, there are more opportunities to simplify the design. Instead of building code in preparation for more future additions, Don Wells suggests writing it for the features you intend to implement right away: “The best approach is to create code only for the features you are implementing while you search for enough knowledge to reveal the simplest design. Then refactor incrementally to implement your new understanding and design.”
Coding Standards
A team needs to adhere to a shared set of coding standards and write code in the same formats and styles. The use of standards speeds up the learning process for new programmers and makes it easy for all team members to read, distribute, and refactor code. It also makes it possible to identify who contributed to specific portions of code. Code created in accordance with the same guidelines promotes group ownership.
Collective Code Ownership
This procedure declares that the system design is the responsibility of the entire team. Code can be updated and reviewed by every team member. Developers that have access to the source code won’t encounter a circumstance where they are unsure on where to place a new feature. Code duplication is prevented by the practice. Collective code ownership enables team members to work together more and feel comfortable to suggest new ideas.
System Metaphor
System metaphor refers to a straightforward design with a certain set of characteristics. A design’s structure and understanding by new individuals must come first. They shouldn’t have to spend a lot of time looking over the specifications before they can begin working on it. Second, classes and methods should have consistent names. It is best practice for developers to name objects as though they already exist in order to make the system architecture as a whole more comprehensible.
40-Hour Week
Developers working on XP projects must work quickly, effectively, and maintain the quality of the final result. They must be alert and well-rested in order to meet these needs. Maintaining a work-life balance keeps professionals from being burned out. The ideal workweek in XP should not include more than 45 hours. Only if there won’t be any overtime the next week is one overtime each week permitted.
Comparison of XP to other frameworks
XP is a component of the agile methodology, as we discussed previously. It adheres to the core ideas of agile development, such as frequent releases, rapid development cycles, ongoing customer communication, cross-functional teams, etc. Because of this, XP is frequently mistaken for other well-known Agile frameworks like Scrum, Kanban, and Lean. Check out our comprehensive whitepaper for more information, or consult the infographics for a brief rundown of the key agile methodologies. Here, we’ll quickly contrast them to identify their key distinctions.
However, it’s crucial to emphasize that, despite the fact that many of its methods cross over with those from the project management domain, XP is not actually a project management framework. Therefore, rather than the managerial and organizational characteristics, its main emphasis is on the technical components of development and the use of particular methods.
XP vs Scrum, Kanban, and Lean in a nutshell
Extreme programming vs Scrum
Self-organizing teams are frequently linked to scrum. Additionally, it typically has sprints that last between two and four weeks, whereas XP iterations last between one and two weeks. Additionally, XP is far more adaptable to possible changes within iterations, whereas Scrum forbids any changes once the sprint backlog has been established. Another distinction is that whereas in XP the client prioritizes features and selects the order in which they should be developed, in Scrum the team decides what to focus on first.
Product Owner, Scrum Master, and Scrum Team are the three primary positions in Scrum, which are distinct from those in XP.
There is no requirement to select between XP and Scrum, though. Combining Scrum and XP methodologies is thought to be extremely effective, with Scrum managing the process and XP concentrating on engineering-related elements.
Extreme programming vs Kanban
Kanban rigorously regulates the number of features that may be produced at once and places a lot of emphasis on visualizing the development process. Although both propose small frequent releases and a high degree of flexibility and adaptability to the changing requirements, it is also distinguished by a continuous process while XP includes discrete iterations.
Kanban doesn’t have well defined responsibilities.
Extreme programming vs Lean
Since Lean is more of a concept or approach to the development process and delivering value to the client, it is difficult to directly compare XP with Lean. Its fundamental ideas include cutting waste, making decisions as late as feasible, delivering goods as soon as possible, and others. Therefore, unlike XP, Lean places less emphasis on time-boxed iterations and more emphasis on delivering an MVP quickly and cutting down on time waste.
When to use XP
We may now explore the situations in which the XP technique is appropriate after weighing its advantages and disadvantages and establishing its position among other agile frameworks. It’s crucial to confirm that a company’s size, structure, and knowledge, as well as the experience of its people, allow for the use of XP methods. These are the things to think about.
Remarkably adaptable development. Some systems require regular updates since their functionality features are not constant. XP was created to make it easier for development teams to adjust to rapidly changing requirements.
Risky endeavors. When a client sets severe timelines for a project, teams who use XP methods are more likely to avoid issues related to working on a new system. A high level of consumer participation also lowers the possibility that they won’t like the final product.
Small teams. For teams of up to 12, XP methodologies are effective. Managing such groups is typically simpler, communication is more effective, and meetings and brainstorming sessions may be held more quickly.
Automated testing. Another factor that can influence the choice of XP is the developers’ ability to create and run unit tests, as well as availability of the necessary testing tools.
Readiness to accept new culture and knowledge. Because XP differs from conventional methods for developing software, it may be difficult to know how to put some of its practices into effect. Therefore, it’s crucial that your team and company are prepared to accept change. If you have no prior experience with XP, it is also worthwhile to invite an experienced coach.
Customer participation. As XP mandates collaboration between clients, developers, and managers, make sure your client is constantly accessible to offer input until a project is completed.
As agility principles demonstrate their efficacy, they are growing in popularity. Despite the fact that it is not the most popular methodology, extreme programming offers a number of practical methods that can aid software development and are worthwhile taking into account for use in your projects.
Extreme programming moves slowly into the enterprise
Companies are paying closer attention to novel development techniques, including extreme programming, as they battle to finish application development projects on schedule, within budget, and with a minimal amount of defective code.
While serving as the project manager for Chrysler Comprehensive Compensation (C3), a lengthy effort to replace Chrysler Corp.’s payroll application, programmer Kent Beck created the concept five years ago. Extreme programming involves bringing clients on-site to collaborate with development teams, exchanging coding techniques, teaming up developers, running automated unit tests, and often simplifying code through editing.
According to Christian Wege, portal and Web application architect at the automaker, which generated $152 billion in revenue last year, DaimlerChrysler AG, based in Stuttgart, Germany, still employs extreme programming in a number of its application development groups in the United States and Germany. Wege, however, said that DaimlerChrysler places special focus on just a handful of extreme programming ideas, such as constantly testing units and working in small development teams. Because most development teams are distributed and application development is frequently outsourced, other extreme programming principles, including pair programming, are typically not applied, he added.
However, according to Chris Dial, an analyst at Cambridge, Massachusetts-based Forrester Research Inc., businesses are increasingly relying on novel approaches to make the most of fewer development teams and manage more sophisticated, dispersed applications.
According to Dial, “new sorts of applications, such Web services, have a higher demand for well-structured code, and it’s impossible to skimp on design.”
When Noggin LLC, a New York-based entertainment channel, recently debuted an interactive website that links into the recording of its shows, it adhered to extreme programming development procedures. CodeFab Inc., a development company based in New York, was in charge of leading the project.
Vice President of Programming and Production at Noggin Kenny Miller commented, “We kept breaking [the project] down into several smaller initiatives. “My fear was that the project would collapse under its own weight. [Extreme programming] allowed us to make incremental progress.”
The degree to which IT managers and developers will adhere to each tenet of the many new development concepts, such as extreme programming and agile modeling, is something about which they are less convinced. The majority stated that they are introducing only a portion of these strategies, although some are adopting the entire methodology.
To create call center apps, Capital One Financial Corp., for instance, started an extreme programming project in the spring, according to Steve Metsker, software development manager at the Falls Church, Virginia-based business. Metsker claimed that the group’s use of extreme programming techniques to create a call center application was successful, but he added that the financial services company’s upcoming project to create a customer management application will place less emphasis on particular extreme programming approaches.
Capital One is instead implementing more widespread agile modeling techniques, such as providing usable software rapidly, writing minimal code, getting feedback quickly, and submitting code regularly in tiny units.
“There are some aspects of [extreme programming] that are extreme, and some wonder whether something extreme is right for their company,” said Metsker.
Participants also pointed out that not every organization is a good fit for intensive programming.
According to Ron Crocker, senior technical architect at Motorola Inc., the Schaumburg, Illinois-based corporation implemented portions of the method in some of its development organizations but found that it wasn’t suitable for international development projects. “[Extreme programming] values small teams, and that’s not always possible,” he remarked.
Course Manual 3: Kanban
Kanban basically translates to “billboard” or “signboard” in Japanese. The technique is also a tool for visualizing the ups and downs of teamwork. It was created by Taichi Ohno, an industrial engineer who was employed for Toyota at the time, and was intended to be utilized for manufacturing improvements that were made gradually over time. However, because to its success, it would later permeate a wide range of sectors and businesses.
Kanban boards, which vary greatly because they are tailored to the specifics of the business, sector, or department where they are used, are the most typical way that Kanban is recognized.
The Kanban board examples below nicely demonstrate how they can vary in terms of both complexity and content.
All Kanban boards fundamentally offer the same overall graphical workflow process when reduced to their bare essentials, which can be broken down as follows:
The emphasis on a fluid and flexible workflow, with continuous updates and revisions of priorities within a team, is one of Kanban’s biggest benefits. Kanban allows for gradual improvements over time, encouraging the growth of strong cooperation skills among participants. High accountability makes ensuring that work is completed efficiently and that bottlenecks are immediately found.
Why is Kanban effective for IT Transformation?
The Kanban technique has many benefits for managing change in the particular context of IT transformation.
Apart from limiting the amount of time that “Works In Progress” can be active, Kanban’s intrinsic flexibility implies that it provides flexible task management. In a feedback-rich environment that prevents them from deviating from the plan, teams are encouraged to make some of their own decisions. Teams and their priorities can change to meet shifting needs because to this flexibility. The focus of Kanban, which is to capture the complete workflow process with a single glance at a single board, fits in perfectly with the frequently hybrid working culture of digitally transformed enterprises. Kanban functions just as well, if not better, as a remotely accessible, cloud-based asset for managing the flow of knowledge work away from the workshop floors it was created on. Additionally, Kanban’s all-in-one glance feature makes decision-making at all levels more informed. It puts teams’ work in relation to other teams’ work and the larger business interests that each team is independently pursuing. This comprehensive picture of the work being conducted and goals being worked toward empowers teams with the ability to make logical and educated decisions based on the existing on-the-ground reality because digital transformation is so dependent on the alignment of different assets and channels.
Pixar’s use of Kanban to ‘manufacture’ animation
Edwin Catmull, the co-founder and first president of Pixar, introduced the Kanban method of 3D animation to make sure that every Pixar production was, in essence, manufactured.
The business was able to make sure that each team finished working on its portion of the film before handing it off to the next team, and so on, by utilizing a high-level Kanban board and lean manufacturing concepts. Through the board, everyone could see what the others were working on in the interim.
According to Catmull in his book Creativity Inc., this manufacturing-inspired procedure allowed anybody at Pixar to halt the production line if an error was discovered, preventing it from moving further along the line and becoming more expensive to rectify.
Kanban Methodology: The Simplest Agile Framework
The Agile Kanban Framework places a strong emphasis on visualizing the entire project on boards in order to improve project transparency and team member participation.
One of the most often used frameworks is kanban, which enables project managers to effectively manage and monitor their initiatives. The Kanban framework stands out among other agile techniques for its fit with the current organizational structure.
In contrast to other well-liked frameworks, Kanban favors making only minor yet significant adjustments to the current configuration. Traditional organizations, where hierarchy and the responsibilities of functional managers are valued, like this.
How does Kanban work?
The kanban board is the center of the Kanban technique, as was already explained. It is a tool that helps them track the progress of their project by visualizing the complete undertaking. A new member or an outside party can grasp what is going on right now, what activities have been done, and what tasks are coming up by using the graphical technique of Kanban boards.
Kanban board indicates
• the current tasks that are being performed
• the tasks to do in the future
• the tasks that are completed
Tasks are gradually moved from the leftmost column (future tasks) to the rightmost column through connections between the separated columns (completed tasks). Utilizing the notion of Work in Progress, the Kanban system tracks the progress of each work cycle (WIP). WIP has predefined specified limits and a status.
One of the guiding concepts for the Agile Kanban technique is limiting WIP in order to uphold uniform standards. The team’s completion of the present duties in the designated order is crucial.
Kanban is a pull system
A pull system is a Lean method that regulates work flow by replacing completed work. A classic illustration of a draw system is a vending machine, where new products are only stocked when the old ones run out. This is a perfect fit for Kanban.
Unlike Scrum or Agile, which emphasize sprints and iterations, Kanban focuses on work states. Kanban focuses on dividing work into manageable tasks, visualizing them, and keeping a small number of things in each work state. Work always travels from left to right on the Kanban board. And when you have finished all of your current work items or an urgent task comes up, you choose work from the column to your left. This is made more difficult by the work-in-progress constraints.
When should you use Kanban?
Kanban’s simplicity is also its adaptability. It respects the roles and responsibilities already in place and integrates with your current procedures. No matter the industry, it can be used. It could be used by an e-Commerce company as well as a content editor.
Any knowledge work environment can benefit from the usage of kanban, but it is especially useful when work comes in infrequently or when you want to start deploying work right away rather than waiting for other work items to finish.
Kanban is the greatest choice if your priorities can change on the fly and ad hoc activities can occur at any time because you can add tasks to any work stage. It may also be applied in the absence of iterations.
Why Spotify turned to Kanban
You must be familiar with this well-known music streaming service, which boasts 60 million active customers. They struggled to complete their projects, so they turned to Kanban.
The operations team at Spotify made the decision to simplify Kanban as much as possible. They believe it is crucial that the board not get overworked. The team uses only three workflow categories, To Do (tasks to start), Doing (tasks in progress), and Done, to streamline their workflow (finished).
When a task requires longer time to complete, they also employ certain more cards, such as the “Defer” card. The “Blocked” cards are also used to record jobs that are unable to be completed for whatever reason.
Spotify has optimized its workflow so that it always leaves time for creativity rather than squandering it on unimportant tasks. All staff have access to the Kanban boards and can add new tasks to them.
Core principles of kanban methodology
The ideas and practices of the Kanban technique. The following are the main tenets of the Kanban method:
1. Initiate with the existing workflow:
The Kanban methodology places an emphasis on implementing modest, progressive improvements. As a result, the team must start with the current procedure and continually enhance it.
2. Limit the existing tasks:
The team must be aware of its own limitations and set a reasonable WIP cap. Overcommitting will only result in time loss and a poor outcome for the project.
3. Respect existing roles and responsibilities:
The fact that Kanban does not force enterprises to entirely change their current work culture is a key factor in its success. Many businesses are resistant to new approaches because they don’t like change.
Efficiency is increased using Kanban while remaining within the constraints of the current arrangement.
4. Encourage leadership at all levels:
Even the tiniest tasks must be approved by the project manager according to typical project management approaches. Kanban allows the person completing the task the freedom to decide how to proceed. Future leaders who continually learn from their errors and enhance their job are developed in this way.
Core practices of Kanban methodology
Organizations that employ the Kanban technique have also built the following practices using the aforementioned fundamental principles.
1. Visualization of workflow:
The appropriate depiction of the entire project is key to the Kanban philosophy. The entire industry makes use of kanban board software for this. People used to purchase whiteboards on wheels in the past and use them with the aid of various columns and Kanban cards.
Due to the availability of sophisticated project management technologies that can greatly simplify your life, this strategy is now obsolete.
2. Reduction of WIP:
When using a Kanban system, WIP should be in line with the team’s capacity. WIP is typically capped in order to ensure optimal effectiveness. There is a cap on the number of jobs that can be carried out concurrently on the Kanban board.
As long as the limit is reached, no new tasks can be assigned, ensuring that the entire team collaborates and completes all connected tasks at the same time.
3. Efficient workflow management:
Lead time, or the total amount of time needed to execute a task, is a crucial metric that project teams must minimize as much as feasible.
4. Explicit management policies:
The project team must understand its goals if they are to succeed. The explanation is fairly straightforward: People will work harder to complete a project when they have a clear goal in front of them.
5. Take feedback:
The customer is ultimately the most significant factor for any firm, making the implementation of a strong feedback system crucial.
It is possible to designate a column on the Kanban boards for customer or external reviewer feedback. The standard of the output can be continuously upheld in this way.
Kanban vs Scrum: What’s the Difference?
Together, Scrum and Kanban are regarded as the pillars of the Agile implementation process. The majority of Agile techniques were employed by over 57% of firms, with Scrum and Kanban accounting for the biggest share, according to PMI’s “Pulse of Profession 2019” study.
While both Scrum and Kanban emphasize delivering the product regularly and iterating till perfection, they take distinct approaches to this. The Agile Manifesto’s values and principles are implemented using the Kanban and Scrum frameworks, although they do it in very different ways.
Work is finished in tiny chunks and revolves around a fixed-length “sprint” in Scrum. Kanban, in contrast, emphasizes the practice of continual improvement and activities are carried out in a systematic way.
Similar to Kanban, Scrum demands the completion of a single sprint plan before any changes can be made, but Kanban is task-based and changes may be made at any moment. As a result, Scrum is preferable for projects that call for work to be done in batches, whereas Kanban is a good choice for projects that demand a great deal of flexibility.
Additionally, there are no established positions in kanban, and nobody is in charge of a team or a task.
The roles of the Scrum Master, Product Owner, and Team Members, on the other hand, are already established.
Benefits of Using Kanban Framework
The primary benefit of the Kanban framework is that it allows you to manage your projects more better without altering the organizational structure.
Some of the benefits Kanban methodology offers are:
• Enhanced flexibility
• Continuous improvement
• Increased collaboration
• Employee empowerment
• Smoother workflow
• Better inventory management
• Improved quality control
Making The Best Kanban Platform Decisions To Support Your Transformation
It can be difficult to choose the Kanban platform that most closely satisfies each organization’s particular and special needs because there are so many solutions accessible.
The ideal platform will incorporate task boards and workflow procedures into the larger activities that will be required to actually finish the assignment by utilizing the agility of digital technologies. When it comes to digital transformation, this may entail brainstorming with coworkers and clients, crowdsourcing ideas from social media, or ongoing iterations of concepts that are constantly changing.
How Apple uses Kanban
Apple is an American multinational firm that creates and sells computer software and consumer electronics goods all over the world. With about 97,000 employees using Kanban to manage their workflow globally However, the modified form of Kanban utilized here is referred to as “Dynamic Kanban,” which assists staff in prioritizing work in accordance with the demands of the moment.
The Apple workflow begins with a backlog part; following that, the work is done by various teams in the “Doing” area, which leads to the “Done” portion. Workflow within the company is broken down into stages like “Ready,” “Doing,” and “Done.”
They add a card to show that each stage has been successfully completed at the end of it. It aids in maintaining attention on fresh activities and finishing them as quickly as possible. Because everyone works together to accomplish their objectives in a collaborative setting, Kanban works effectively for Apple.
Course Manual 4: Scrum
Agile scrum methodology is a sprint-based project management system with the goal of delivering the highest value to stakeholders.
• Agile and scrum are two similar project management systems with a few key differences.
• Agile is more flexible and promotes leadership teams, while scrum is more rigid and promotes cross-functional teams.
• Agile lets teams develop projects in small increments called “sprints” and allows for more effective collaborations among teams working on complex projects.
Companies of all sizes adopt the agile scrum methodology because it enables excellent project-based teamwork and productivity. The agile scrum technique is the most widely used use of agile. Agile and scrum are two distinct methodologies that can be utilized separately. The whole guide to agile scrum methodology is available here.
Did you know?:Agile and scrum can be used independently, but the benefits of the methodology as a whole make it popular.
How does agile scrum work?
The agile scrum technique combines the scrum framework and the agile philosophy. Agile refers to incremental development, enabling teams to create projects in manageable chunks. One of the numerous varieties of agile technique is scrum, which is recognized for segmenting projects into sizeable units called “sprints.” Agile scrum methodology is advantageous for companies that must complete particular projects fast.
Agile scrum methodology is an incremental development-based approach to project management. Each iteration consists of two to four-week sprints, with the aim of completing the most crucial features first and producing a potentially marketable product at the end of each sprint. In succeeding sprints, the product is expanded, and adjustments are made in response to stakeholder and consumer feedback in between sprints.
Agile scrum methodology is centered on delivering multiple iterations of a product to stakeholders in order to deliver the highest business value in the shortest amount of time, in contrast to other project management methods that emphasize building an entire product in a single operation from beginning to end.
The agile scrum technique has many advantages. First, since each set of goals must be accomplished inside each sprint’s time limit, it promotes the development of products more quickly. It also necessitates frequent goal-setting and planning, which aids the scrum team in concentrating on the goals of the current sprint and boosting output.
Companies that effectively use Scrum: ING
Sector: Banking
ING is recognized as the 16th largest financial institution in Europe and is one of the top banks in the Netherlands. By adhering to the values of openness, scrutiny, and adaptation, ING applied the Scrum methodology to improve operational flow and the foundation of its software.
Scrum provided for the governance of all operational levels and operations at a higher level and with a clear understanding of the ultimate product, leading the product backlog, sprint backlogs, and promoting idea sharing. ING’s IT services and delivery channels were improved with the use of innovation and creativity, which ultimately helped to match business goals with portfolio management tasks for increased productivity.
Companies that effectively use Scrum: Vodafone
Sector: Mobile Communication
With a market valuation of £52.5 billion, Vodafone operates in 26 countries and has 50 additional partner networks in other nations. In order to completely overhaul their corporate architecture and make sure that the software team was focused on the main business goal, the Turkish office of Vodafone employed Scrum.
By tackling transformative components one sprint at a time while preserving a crucial respect for the larger business picture and for improved operational system quality, the Scrum backlog facilitated such adaptability. In contrast to the previous case studies listed above, Vodafone established its team by selecting a small team of leaders, which promoted the involvement of people with the knowledge and expertise necessary to impact change swiftly and successfully.
What is scrum?
Scrum is a framework for successful team interactions when working on complicated goods, to put it briefly. Scrum is a kind of agile technology that uses meetings, roles, and tools to improve teamwork and workload management for teams working on complicated projects. Scrum can be helpful to any team working toward a similar goal, even if software development teams are the ones that utilize it the most frequently.
Who can benefit from scrum?
Although scrum can be helpful for many different types of firms and projects, the following are the most likely winners:
• Complicated projects: Scrum methodology is ideal for projects that require teams to complete a backlog. Scrum breaks down each process into bite-sized chunks that can make a complex project easier.
• Companies that value results: Scrum is also beneficial to companies that value results over the documented progress of the process. This is because scrum is focused on efficiency and innovation to drive results, rather than a detailed, rigid process.
• Companies that cater to customers: Scrum can help companies that develop products in accordance with customer preferences and specifications. Scrum is adaptable to change, making it key when responding to customer requests.
What are the benefits of agile scrum methodology?
The following are a some of the overall advantages of the agile scrum methodology:
• Flexibility and adaptability
• Creativity and innovation
• Lower costs
• Quality improvement
• Organizational synergy
• Employee satisfaction
• Customer satisfaction
The flexibility of the agile scrum technique is its main advantage. The scrum team often receives feedback from stakeholders following each sprint when using the sprint-based approach. The scrum team can easily and swiftly modify product goals during next sprints to deliver more beneficial iterations if there are any issues or adjustments. Stakeholders are happier as a result of getting exactly what they wanted after being involved at every stage.
Contrast this with conventional project management methods, where stakeholders rarely offer feedback and time is wasted making adjustments to the product in the middle of the development process, or even worse, where teams are forced to start over after the product has already been developed.
An internal scrum specialist or an external consultant is required to ensure that scrum principles are being utilized effectively when implementing agile scrum methodology. Agile scrum approach requires exact execution and, if not done correctly, could lead to major issues.
Advice: To deploy agile scrum, you’ll need a firm expert or a third-party consultant.
What are the different roles in agile scrum methodology?
There are two kinds of roles in the agile scrum methodology: the core roles, also known as “pigs,” and the supplementary roles, often known as “chickens.”
Scrum master, product owner, and scrum team are the three main roles. These individuals are all devoted to the scrum project.
1. Scrum master: The facilitator of the scrum development process is the scrum master. The scrum master not only holds daily meetings with the scrum team but also ensures that the scrum rules are being followed and used as intended. Along with mentoring and inspiring the team, the scrum master is also responsible for removing obstacles from sprints and making sure the team is in the best environment possible to accomplish its objectives and generate deliverables.
2. Product owner: The stakeholders, who are often customers, are represented by the product owner. The product owner establishes product expectations, tracks product changes, and manages a scrum backlog, a comprehensive and continuously updated to-do list for the scrum project, to make sure the scrum team is consistently delivering value to stakeholders and the business. The product owner is also in charge of ranking each sprint’s goals according to their importance to the stakeholders so that the most crucial and deliverable features are created in each iteration.
3. Scrum team: The scrum team is a self-organized collection of three to nine people who possess the business, design, analytical, and development skills necessary to carry out the real job, address issues, and create deliverable products. The scrum team’s members self-manage tasks and share accountability for achieving each sprint’s objectives.
On the other side, ancillary responsibilities are played by additional stakeholders who are active but not committed to the scrum project. Customers, managers, and members of the executive team typically play supplementary roles in businesses. They are involved for consulting, reporting progress, and receiving feedback in order to give the maximum value possible.
What is the training for scrum and agile?
Scrum and agile training is available to managers and staff through a variety of online and live courses. Scrum or agile techniques certification is available through a variety of educational training programs. Agile training equips the learner with the fundamentals of the methodology and teaches them how to apply it to the rest of their team. Similar training is offered by scrum, including an introduction to agile practices; however, the training is specific to the scrum framework.
You must first study and grasp the fundamentals of scrum through videos or a quick online search in order to become a certified scrum master (CSM) or certified scrum product owner (CSPO). Next, look online or at your place of employment for an appropriate CSM or CSPO course. To become certified after completing the course, you often need to pass an exam. Following certification, you are qualified to guide your team through the scrum process or offer information on the scrum product.
What are the differences between scrum and agile?
Although scrum and agile are similar, they have some key differences:
• Scrum values rigidity, whereas agile is more flexible.
• Agile leaders play a vital role, while scrum promotes a cross-functional team that is self-functioning.
• Agile involves face-to-face interactions between cross-functional team members, while scrum involves daily stand-up meetings.
• Agile is meant to be kept simple, while scrum can be innovative and experimental.
• Scrum delivers shorter, separate projects, while agile delivers everything at the end of the process.
Companies that effectively use Scrum: Netflix
Sector: Media
With 98 million subscribers globally, Netflix is the biggest entertainment media company in the world. Netflix employs the Scrum paradigm because it needs to produce items and jobs fast to meet client demand and guarantee operational flow is attained before its rivals. Every two weeks, Netflix does system maintenance using the quick iterative design approach, which ensures that deadlines are fulfilled and that resources are used effectively.
Netflix has been able to experiment with new features while adhering to the Scrum structure, knowing that there are minimum risks and resources wasted. This has allowed them to maintain their market-leading position and experience exponential growth.
Companies that effectively use Scrum: Adobe
Sector: IT – System Development
The industry standard for video editing software is Adobe Premier Pro. Adobe used the Scrum methodology to improve market perspective, such as recommendations, and to get rid of and fix software bugs and technical debt. Because everyone on the Scrum team was treated equally and there was no dictatorial style of leadership, communication amongst relevant engineers improved.
The development team was able to remain focused and avoid being overburdened with too much unimportant information thanks to the product backlog, which allowed the Scrum Product Owner to divide the job into useful but smaller sprints. The Scrum team was created using a blend of personality traits and talents, ensuring that the ideal qualities for maximum productivity and cohesion were present.
Course Manual 5: Disciplined Agile Delivery (DAD)
A flexible framework for Agile software delivery is called “disciplined agile delivery” (DAD). It prioritizes learning and puts people first in the creation and delivery of software.
DAD is an umbrella term for a number of other frameworks used by Agile software development teams, including Scrum and Lean software development. It offers an Agile strategy that simplifies IT work at an enterprise scale by filling in the process gaps between existing Agile approaches.
Core principles of Disciplined Agile Delivery
The core principles of DAD are as follows:
• Delight customers. The team should keep customers in mind during beginning phases of development and businesses should seek feedback post-deployment to maintain satisfaction.
• Be awesome. Teams should be motivated, engaged and engaging. This promotes dependability and trust on the team and in the larger organization. Teams should also focus on product quality from the very beginning.
• Context counts. A team, its members, and the enterprise are all unique entities with unique goals and ways of working. None of them exist in a vacuum, and teams should consider the environment’s effect on the individual entity as each affects one another.
• Be pragmatic. Agile principals are sometimes followed rigidly by the teams that practice them, which requires ideal conditions that are rarely present in the real-world enterprise. DAD encourages teams to be pragmatic rather than idealistic, and not to follow Agile strictly if there is a more efficient approach.
• Choice is good. This encourages teams to choose the strategy that maximizes benefits. It promotes a middle ground between entirely experimental approaches and entirely prescriptive ones, giving teams a structured set of options but not prescribing any one of them.
• Optimize flow. This involves keeping work in progress to a minimum, visualizing workflow, eliminating waste, continuing improvement and experimentation, and clearly defining metrics for success. It also signals a preference for stable, sustainable teams with low employee turnover.
• Organize around products/services. Teams should organize their efforts around the product or service the end user desires. Similar yet more explicit than value streams, the team should focus development around what the customer needs.
• Enterprise awareness. The team should understand their place in the larger enterprise architecture. This includes knowing how a team’s process and output affects external teams, and vice versa.
The phases and lifecycle types of the DAD framework
Inception, construction, and transition are the three key stages of the DAD framework that identify stages in product development.
In DAD, there are six different delivery lifecycle types, and each one includes three phases with a little bit of a different personality. Lifecycle kinds include:
• The Agile Lifecycle. This type is Scrum-based, iteration-based, and includes milestones and a work item list instead of a product backlog.
• The Lean Lifecycle. This type is Kanban-based. The main difference between this lifecycle and Agile is that meetings and iteration planning sessions are held on an as-needed basis. In Agile, meetings are prescribed and held consistently.
• Continuous Delivery: Agile Lifecycle. This lifecycle is an evolved version of the Agile lifecycle with shorter iterations.
• Continuous Delivery: Lean Lifecycle. This is essentially the Lean lifecycle with shorter iterations and more frequent releases.
• The Exploratory Lifecycle. This lifecycle focuses on a “fail fast” philosophy, where many different strategies are attempted to get a picture of what the market wants. This type is best for situations in which the product is not yet clearly defined.
• The Program Lifecycle. This lifecycle focuses on organizing teams of teams, or the rare large Agile team.
The lifecycle type that a team chooses should fit the needs and capabilities of the team. Each lifespan has unique benefits and drawbacks.
How Barclays Bank used DAD
Approach: Disciplined Agile Delivery (DAD) & Agile Coaching
Barclays’ transformation to Agile was not a coincidence. The financial services company actually implemented a sizable, company-wide plan that was entirely justified given their size and organizational structure.
Barclays sought to develop a more successful method of changing the mindset among its teams, which are spread across multiple nations. They were able to provide people-first coaching that would assist teams in streamlining process decisions and increasing productivity by employing Disciplined Agile Delivery (DAD). In order to make many workspaces more collaborative and less personal, they also started revamping them.
Result: Throughput increased by 300%, 80 apps’ code complexity was reduced by 50%, and test code coverage increased by 50%. 800 teams at Barclays have successfully transitioned to an Agile methodology, citing higher levels of pleasure, quicker product launches, and greater adaptability than previously, enabling them to react more quickly to internal feedback or outside developments. With such flexibility, Barclays has been able to offer small company recommendations based on their successful experience and increase their new client rates in the post-Covid environment.
Model team roles in DAD
DAD identifies the following five core responsibilities that are present in Agile teams and organizations of all sizes:
• Stakeholder. This is anyone materially impacted by a product’s outcome, like a user, someone related to a user, a manager, or a product owner. Anyone with a stake in the product’s success fits this role.
• Product owner. The product owner speaks for the customer. They represent the customers’ needs to the stakeholders and team members.
• Team member. Team members have a direct part in producing the product. They identify and perform tasks and track their statuses as they work. They work with the team frequently to minimize requirements, testing and documentation. They maintain the list of work items for the team to complete and communicate progress to stakeholders.
• Team lead. The team lead acts as a servant leader, coaching and guiding the team through technical management activities and creating the conditions for the team to be successful.
• Architecture owner. Their responsibility is to minimize risk posed by architecture. They have a strong understanding of the business domain as well as a technical background. They facilitate the overall design of the product, remove impediments to the team and provide resources to help ensure success.
There are also a number of auxiliary functions that are depending on the situation and occasionally transient. They are frequently used to address scale-related problems. Here are some of them:
• Specialist. Larger teams, or teams working in more complex areas, may require a specialist. An example would be a business analyst that joins to help explore product requirements.
• Domain/subject matter expert. They are sometimes introduced by the product manager to help answer team questions and explain specific requirements or the overall vision of the project.
• Technical expert. Technical experts can join temporarily to solve especially difficult problems and/or transfer their skills to team members.
• Independent tester. This role supports DAD teams by working alongside them and validating work throughout lifecycles.
• Integrator. They focus on integrating especially large teams that require a separate position to make sure they all function as a unit.
These roles are by no means set in stone. Each person can play any role at any moment, and in some circumstances, they can play several roles simultaneously. A self-organizing team’s responsibility includes offering to take on and fill these tasks as needed.
Examples of Disciplined Agile Delivery
DAD was invented by software developers, but it also applies to other kinds of labor. It can be used by any Agile team that wants to deliver a product while dealing with changing conditions. One illustration is a group of writers assigned to manage continual delivery of web material throughout time. The team may plan, create, and distribute content using DAD’s Agile and Lean principles, including Scrum and Kanban, while utilizing feedback loops to modify as needed. Another illustration is portfolio management, where teams use DAD to choose and oversee projects in order to accomplish strategic goals.
DAD vs. SAFe
Although they serve the same purposes inside an organization and are both large-scaled Agile frameworks, DAD and SAFe (Scaled Agile Framework) take various approaches to Agile management. DAD is thought to be less rigorous than SAFe. Also, it adopts a more top-down strategy and has a more directive character. DAD adopts a bottom-up, less directive approach and focuses on enhancing procedures rather than adhering to one. It prioritizes adaptation above all else and is thought to be more flexible than SAFe.
Why Disciplined Agile® Delivery?
There are a number of reasons why you ought to think about adopting DAD. As follows:
• DAD picks up where Scrum leaves off. DAD describes how all agile techniques fit together, going far beyond Scrum, to define a full agile solution delivery life cycle. Like Scrum the DAD addresses leadership, roles & responsibilities, and requirements change management. Unlike Scrum, DAD doesn’t stop there, it also addresses other important aspects of software development such as architecture, design, testing, programming, documentation, deployment and many more. In short, DAD provides a much broader understanding of how agile development works in practice, doing a lot of the “heavy process lifting” that Scrum leaves up to you.
• DAD is pragmatic. The DA toolkit provides choices, not prescriptions, enabling you to easily tailor a strategy that reflects the situation that your team finds itself in. To do this effectively you need to understand the process-oriented choices you have and what the trade-offs are. DAD makes these choices explicit through its process-goal driven approach.
• DAD supports both lean and agile ways of working (WoW). DAD supports several delivery life cycles, including a Scrum-based agile life cycle, a Kanban-based lean life cycle, two continuous delivery life cycles, a Lean Startup-based exploratory life cycle, and a Program life cycle. Teams find themselves in unique situations, and as a result one process size does not fit all. Even in small companies we’ve seen situations where some teams are taking an agile approach, some a lean approach, and some combinations thereof.
• DAD is based on empiricism. DAD, and the DA tool kit in general, captures the proven strategies adopted by organizations, describing the strengths and weaknesses of each strategy and providing guidance for when and when not to apply them.
• DAD provides a solid foundation from which to scale agile. DAD supports successful scaling of agile and lean techniques in several ways. First, its full delivery life cycles and breadth of software development advice answers how to successfully apply agile in practice. Second, its goal driven approach provides the required flexibility for tailoring your agile process to meet the challenges faced by agile teams working at scale. Third, DAD builds in many foundational concepts required at scale, including DevOps, explicit agile governance, and enterprise awareness.
• DAD enables and goes beyond SAFe. SAFe leaves the details of construction to you and as a result can prove to be fragile in many organizations. DAD provides the solid process foundation missing from SAFe and is in fact complementary to SAFe. DAD describes several strategies for organizing large or geographically distributed teams. It describes a range of options for scaling your approach to agile and lean software development, giving you context-sensitive options that SAFe doesn’t.
• DAD teams deliver solutions, not just software. DAD recognizes that the software we develop runs on hardware, which may need upgrades, and it is supported by documentation. Stakeholders may also need to evolve their business processes, and sometimes even their organization structures, to address the new needs of the situation that they face. In short, DAD teams deliver consumable solutions that comprise software, hardware changes, supporting documentation, improved business processes, and even organizational changes.
• DAD is evolving. We’re constantly learning as practitioners, learning about and experimenting with new agile and lean strategies all of the time. These learnings are constantly being applied to evolve DAD.
• DAD is a critical part of your Disciplined DevOps strategy. DAD is the “Dev” part of Disciplined DevOps. It includes explicit advice for a range of development strategies that enable DevOps.
Figure 1. The Workflow of Disciplined DevOps.
How Panera Bread used DAD
Approach: DaD
The hugely successful and well-liked bakery-café company Panera Bread, which has more than 2,000 locations across the US and Canada, is last but certainly not least on our list.
The company’s growth has also been exponential since 2013, when it employed about 250 people to provide IT services throughout the entire organization. At this point, the President voiced his concerns regarding the IT team’s capacity to keep up with the rate of development and expansion of the company, particularly given that Panera Breads used a typical mix of custom-built applications and off-the-shelf software products.
Panera chose to change their methodology and use Disciplined Agile Delivery to address this issue and speed up the efficient supply of IT services in a way that supports company-wide growth (DAD).
Agile training sessions were first given to the executive teams as part of this approach. After receiving the same training, relevant delivery terms were then prepared for the start of two prototype DAD projects. In order to streamline ordering procedures and enable speedier and more frequent deliveries, the pilots concentrated on back-of-the-house functions like forecasting, labor scheduling, and inventory.
After this, Panera Bread used DAD to install user-friendly and high-quality IT solutions everywhere, greatly improving the connection between the company’s digital operations and the efficiency of each physical location. Another crucial component of strategy centered on improving the mobile ordering experience, to assist improve sales and significantly raise customer happiness.
As a result, Panera Breads has increased its digital sales to 25% of total sales by streamlining the mobile ordering process. Also, the brand now offers one of the fastest and most effective customer loyalty programs in the sector, and shipping efficiency and speed have both increased.
Course Manual 6: Lean Development
Guiding principles of lean development
Without a doubt, properly and efficiently digitizing value streams will give a company a competitive edge in the future. Yet, senior management must concentrate on creating the appropriate capabilities and a necessary mentality throughout the business in order to carry out such an IT transformation – a requirement also shared by lean management.
It is now widely acknowledged that digital technologies have the power to change performance. Unfortunately, the majority of businesses fail to identify the best strategy for properly utilizing this digital promise’s advantages. It is difficult to choose among the vast array of new alternatives offered by digital technologies. Usually, it is unclear how to prioritize a company’s efforts and resources in order to produce measurable results. While some businesses have been successful in achieving dramatic performance increases of up to 50% or more, many are stuck in situations where initiatives take place in silos, efforts are disorganized, and results are few or nonexistent.
Experience in recent times has demonstrated that applying lean concepts to digital transformation can be a highly successful means of achieving dramatic process reduction. It enables businesses to determine and use the best levers for their digital transformation.
Implementing lean phases and considering the value stream holistically
Businesses that follow lean principles outperform their rivals in terms of performance levels. The lean lifespan was divided into three phases in a recent automotive study by Arthur D. Little, and the rates of yearly firm growth in each phase were calculated. The link with lean implementation was examined using “hours per vehicle” as a major automotive productivity indicator.
Up to 8% performance growth was typical during the Lean Exploitation phase. As performance increased, this declined and tended to stabilize at about 1% during the Lean Excellence phase. Digital technology have the potential to advance all phases much farther.
Nonetheless, many lean trips fail despite the fact that these principles are well understood. Businesses frequently place an excessive amount of emphasis on waste collection and tools rather than client value. This failure frequently manifests as lean “fatigue” and depressing incremental improvements.
Unquestionably, the emergence of new digital technologies offers tremendous opportunities and levers for achieving an additional step change in performance. Companies that just implement new technical systems and devices without taking the value stream into full consideration run the danger of failing. This is due to a number of factors, such as:
• Issues related to deficient value streams and/or poor data quality are seldom overcome by using sophisticated technologies
• Digitalization of processes with poor (data-) quality risks make existing shortcomings even worse
• The local, workplace-specific application of technological gadgets seldom leads to radical simplification at the enterprise level
• Technologies which, at first sight, seem easily applicable may lack maturity, causing frustration for employees
• Radical simplification requires a holistic approach to value-stream transformation
Selecting and integrating the right technological building blocks
Each organization must set up its own set of technology building blocks to address its organizational aims and characteristics. The “Future of Operations” paradigm for digitization by Arthur D. Little defines five categories of technology building elements. This classification aids businesses in linking operational requirements to the appropriate building block:
• Cognitive: using pattern recognition based on (big) data for automating tasks (e.g., big data/advanced analytics, bots, autonomous transport systems)
• Connected: incorporate machines, tasks, etc., through the cross-functional use of information (e.g., collaborative, smart machines and robots)
• Virtual: leverage productivity by decoupling and transforming physical conditions into virtual spaces (e.g., cyber-physical systems, augmented reality)
• Human centered: design new workplaces through the use of collective knowledge (e.g., collective intelligence, virtual workplace)
• Value-add: define new business models through the use of new core technologies (e.g., additive manufacturing/3D printing)
Due to the linked nature of these building pieces, an all-encompassing and integrated design approach is required. They apply across the entire organization, in both supporting roles like robotic process automation (“RPA”) in production planning and finance and core operating roles like manufacturing and shipping. Using lean concepts makes it much simpler to pinpoint the necessary areas and modify levers.
Developing a design approach to reach full digitalization potential
Using a design strategy based on two essential issues, the value stream’s entire digitalization potential may be determined.
1) Which steps of a physical process can be automated using established and reliable technologies?
Create a lean value stream first on a clean slate. Eliminate interfaces through consolidation and integration to drastically simplify the value stream and make the value added obvious. Ask why each process step needs to be completed by a worker and what technology it should use to be automated, paying particular attention to the non-value-adding (“waste”) steps. On standardized processes, the immediate application of mature technology building blocks will result in more reliable processes with fewer failures. By concentrating on adding value rather than removing waste, productivity has increased significantly.
The greenfield value-stream design shows the value stream’s digital potential, which is a significant departure from the existing value stream.
2) What non-physical (information) process stages are left that can be completely digitalized?
Second, automate and digitalize traditional decision-making and manual information processing. Aim for a target condition where all automated quality gates are monitored and confirmed by the employee. eliminate all manual intervention. RPA, artificial intelligence, or decision-supporting systems drastically reduce administrative information flows, especially for high-frequency routines where employees transfer data between programs or even for very complicated choices. In addition to reducing errors and speeding up operations, digitalized information flow also generates new value and improvement opportunities due to big data’s increased digital visibility.
Conclusion
To successfully digitalize its value stream, top management must prioritize building the necessary competence and instilling the necessary mindset throughout the business, just like with lean management. The faster efforts to digitalize are successful in bringing about step changes in corporate performance, the more employees and management will adopt this new lean digital way of thinking.
Systems of engagement: key drivers of a lean digital transformation
The user’s daily interaction with digital tools and trends is mediated by the systems of engagement. Systems of engagement are dynamic and rely on user-friendly platforms or apps whose worth is correlated with the degree of user involvement as determined by the quantity and caliber of interactions. Systems of engagement are an evolution of the long-standing IT paradigm of systems of record, which are based on significant legacy data storage and retrieval systems like the corporate ERP modules currently in use. Examples of systems of engagement include social apps like LinkedIn and Facebook or business platforms like Uber and Airbnb.
By combining a high quality user experience with high user-related value creation, a system of engagement is intended to encourage user involvement. More value generation leads to greater involvement, which in turn leads to greater data generation, which can then lead to greater value generation.
The basis for developing a Lean Digital Transformation Agenda, which serves as the launchpad for organizing the whole Digital transformation effort, is an understanding of the workings of systems of interaction.
Digital waste & data profit
The exponential proliferation of available unstructured data, such as text, videos, audio messages, and other formats, is a result of the rapid increase in the number of systems of engagement.
Through the use of data analytics tools, this unstructured data has the potential to be a source of valuable information that can be “harvested.” The majority of information, however, is currently wasted and disappears unaccounted for.
Digital waste is all unaccounted-for data or data paired with incorrect or misleading information. Whoever is unable to utilize the “rich” of data available wastes valuable resources. Data profit is defined as all data combined with relevant information for the user, permitting him to make the correct choices.
Lean Digital: What is it?
Lean focuses on minimizing consumer value while eradicating conventional waste. Instead, Lean Digital focuses on minimizing data loss while eradicating digital waste.
Lean Digital eliminates digital waste, which suggests a significant improvement in user engagement and experience.
Also, this will start a “virtuous” cycle that will enable continual growth in data gathering and user experience.
This fosters the ideal climate for Lean digitization-led sustainable change.
Many businesses have not even begun to address the fundamentals of conventional Lean waste reduction, which has expanded and become critically important levels of complexity and non-transparency in their organizations, processes, products, and services.
FedEx’s Lean Management
FedEx Express
FedEx Express, which is more often recognized for sending mail and deliveries, is dedicated to maintaining ships and airplanes.
Over 170 facilities operated by FedEx Express are located throughout the world, with about 100 of them in the USA. As enormous operation and responsibility, maintaining an aircraft requires a lot of money, space, manpower, and financial resources.
The “C-check” is one of the key services offered to airplanes. Although the exact meaning of this phrase varies, it can be used to allude to the aircraft’s general upkeep.
After the 2008 financial crisis, FedEx Express adopted lean management in an effort to cut costs during difficult times. The success of the company has since considerably benefited from this operating strategy.
FedEx’s Problems and Solutions
Let’s concentrate on the FedEx Express facility at Los Angeles International Airport out of all the places (LAX). The staff could do 14 C-checks annually before they started using the lean management strategy.
The crew was able to execute 30 C-checks annually after applying the principles of lean management.
The FedEx Express LAX team needed 32,715 hours to finish an aircraft’s C-check before implementing lean management techniques. That figure is falling off over time. The crew once only required 21,535 man-hours to complete the identical C-check.
Setting milestones was one way the operations were altered to reap such significant benefits and gains. The team came together to define each segment using 4-hour increments and to select 68 milestones that are essential to the C-check.
Finding the milestones facilitated a more efficient workflow, which reduced time wasted. In a high-tech business like aviation maintenance, where it is very expensive to employ expert mechanics, specialists, and personnel, eliminating lost time is a big money saving.
Course Manual 7: Scaled Agile Framework (SAFe)
What is the Scaled Agile Framework (SAFe)?
An agile framework created for development teams is called the Scaled Agile Framework, or SAFe. The three metaphorical pillars that make up SAFE’s basis are Team, Program, and Portfolio. SAFe also offers a product team freedom. Also, it aids in addressing some of the difficulties that bigger organizations encounter when implementing Agile. SAFe is made up of a significant knowledge base of tried-and-true best practices. Similar to how development teams use SAFe to produce successful software solutions.
What’s the History of the Scaled Agile Framework?
The SAFe framework began to gain traction in the product industry in 2011. Agile Software Requirements author Dean Leffingwell, a veteran of the software industry, first referred to the SAFe framework as the “Agile Enterprise Big Picture.” Lean, Kanban, Scrum, and XP are a few examples of agile frameworks that can be applied at the Team, Program, and Portfolio levels, according to the “Big Picture” strategy.
The vast majority of SAFe’s expertise and success patterns are now freely accessible. One of the most well-known agile frameworks is still SAFe.
What are the SAFe Agile Principles
SAFe is based on the following 10 fundamental principles:
Principle #1 Take an economic view
Achieving the lowest sustainable lead-time necessitates that everyone involved in the decision-making process is aware of the financial ramifications of delays. This idea is drawn from the theories on product development flow presented in Donald Reinertsen’s best-selling books. Early and frequent delivery isn’t always sufficient. According to SAFe, the business as a whole must share responsibility for understanding economic trade-offs, functioning within limited budgets, and scheduling jobs for maximum advantage. Reinertsen’s beliefs on the flow of product development are the source of many of the concepts and tools.
Principle #2 Apply systems thinking
Applying systems thinking to three crucial areas—the solution itself, the enterprise creating the system, and the value streams—is encouraged by SAFe. Whether they are internal or external to the Enterprise, solutions can relate to any goods, services, or systems that are provided to the Customer.
Team members should have a higher-level perspective on how their component fits into the overall picture because large solutions have many interconnected component pieces. Those who adhere to SAFe should think about the enterprise constructing the system while taking into account its management, people, and processes. Hence, if a company wants to improve how people operate, it could have to do away with silos, become cross-functional, and establish new working relationships with suppliers and clients. Finally, the business should specify exactly how value streams for solution development flow from concept to revenue. Management and leaders must work to maximize value transfer across organizational and functional boundaries.
Principle #3 Assume variability; preserve options
Designing software and systems is by nature an uncertain task. By incorporating the idea of set-based design, which calls for keeping a variety of needs and design possibilities for a longer period of time throughout the development cycle, this philosophy resolves uncertainty. The set-based design additionally makes use of empirical data to further focus attention on the chosen design alternative.
Set-based design, which is similar to placing a strategic wager, assists in guiding decision-making during times of ambiguity by identifying the possibilities and desired results. Set-based design relies on the idea of incorporating “learning milestones,” which refers to a deadline for a choice. Teams can narrow down their options as they gain experience. It becomes simpler to choose the best course of action and deliver the finest results for clients the more options they eliminate.
Principle #4 Build incrementally with fast, integrated learning cycles
This principle uses learning milestones to address risk and uncertainty, much to Principle #3. The system as a whole must be taken into account in order to evaluate the viability of the present design decisions; it is not sufficient for each component aspect of the system to demonstrate functionality. To speed up learning cycles, integration points must be planned on a regular frequency. These integration points serve as an illustration of Walter A. Shewhart’s plan-do-check-adjust cycle, a system for managing development unpredictability and a framework for continuous quality improvement. The work of Shewart and the work he inspired is frequently found in SAFe.
Principle #5 Base milestones on objective evaluation of working systems
An actual operational system’s demonstration offers a more reliable basis for decision-making than a requirements document or another superficial assessment of success. Early involvement of stakeholders in such feasibility decisions promotes systems thinking and trust-building.
Principle #6 Visualize and limit Work in Process (WIP), reduce batch sizes, and manage queue lengths
Limiting the amount of work in progress enables stakeholders to track the progress of the project.
The three components of this principle, or “flow,” are the main strategies for increasing throughput and speeding up value delivery. According to a proverb “How do you eat an elephant? One bite at a time.”
In terms of software development, this implies keeping the complexity of each individual task, the amount of work that can be completed at once, and the amount of overlap between tasks to a minimum. Lower batch sizes provide ongoing verification of the direction of the effort. Also, controlling queue lengths.
This principle aims to provide direction on how to optimize for this for the best outcomes.
Principle #7 Apply cadence, synchronize with cross-domain planning
With sprints or iterations, agile teams naturally use cadence. Developing a rhythm for every scenario lowers complexity, deals with uncertainty, develops muscle memory, upholds quality, and fosters cooperation. When these cadences are in sync, individuals and activities can function like cogs in a wheel, where decisions are made using learned information and incremental planning is done.
Principle #8 Unlock the intrinsic motivation of knowledge workers
This idea is one of our favorites and was inspired by well-known management guru Peter Drucker and author Daniel Pink. It involves maximizing team potential and assisting leadership in switching from a command-and-control mentality to one of coaching and serving their teams.
Principle #9 Decentralize decision making
Teams are given the liberty they need to complete their work by reducing wait times and adopting a cost-effective strategy by decentralizing decision-making. For matters of strategic importance, leaders should retain the right to make decisions, while allowing teams to make decisions on all other matters.
Companies who adopted SAFe: LEGO Digital Solutions
The well-known toy brick manufacturer’s division for digital contact with clients through wearables, apps, and other channels is called LEGO Digital Solutions. When the group grew to more than 20 teams from its initial five development teams that could readily collaborate, additional difficulties emerged.
Teams were succeeding with Scrums and sprints, but they were experiencing trouble with platform development, client cooperation, cross-team alignment, and release planning.
The team implemented the SAFe framework to add a program level between the teams and the portfolio management procedure at the top of the company in order to address these problems. As a result, there has been less duplication of effort, less dependency-related trouble, better planning and execution, and increased client confidence.
SAFe Project Management
An organization employing SAFe has three tiers of project management. At the level of the particular team, Scrum operations are essentially unaltered.
Small teams have clear objectives and accountability responsibilities. They so publish revisions following each Sprint. Moreover, a Scrum Master usually takes the lead. The only notable modification is that these little teams now form programs.
The program level is where SAFe’s advantages start to become apparent. Here, the work from each team must combine with that of everyone else to create something complimentary, consistent, and cohesive.
They collaborate as a part of an Agile Release Train under the direction of a Release Train Engineer. The synchronization completes the work of several separate Scrum teams. A Potentially Shippable Increment goes through a full round of testing after about five Sprints. The method differs from more conventional Scrum and Continuous Delivery. Code gets shipped a lot more often in this situation.
Portfolios made up of several programs are defined at the highest level with longer-term goals spanning several quarters or even the entire year. Strategic planning and project planning meet at this point, where budgeting, epic-level milestones, and other planning-related issues are defined and established.
Scaled Agile
Agile wasn’t designed with scale in mind at the outset. The intention was to free developers and engineers from constraints and enable them to approach implementation independently, using their own best judgment, and incorporating lessons learned into subsequent iterations.
When there are numerous teams working independently, such unrestricted independence doesn’t work as well, especially when each team’s separate projects must cooperate, share a common interface, rely on a shared architecture, etc. Things may easily spiral out of control.
Thus, additional structure, organization, and monitoring are required in order to maximize the benefits of Agile while acknowledging the necessity for compatibility and collaboration. Agile at scale needs more guidelines and regulations to guarantee that the finished product not only performs as intended but also ties together multiple subcomponents with ease and that product suites behave and appear to have been developed by the same firm.
For instance, the numerous Microsoft Office apps each do their own jobs effectively, but what makes the suite even more successful is how easily users can switch between programs with a little learning curve thanks to a shared user experience (UX). It wouldn’t take long for each team to act very differently if the Word team and the Excel team were completely independent.
When developing complex solutions that are too large and intricate for a single Scrum team to handle, Scaled Agile offers that additional layer of administration and coordination. This can be due to a pressing need to get a solution to market or just the fact that the product is too complex and vast.
A more dependable release schedule is produced by scaled agile. Enterprise software companies can make customer commitments and schedule sales, marketing, operations, and customer service to support these launches because it is easier to predict when specific projects, products, components, and features will be released thanks to the coordination that is necessary.
SAFe Versus Scrum
Scrum and SAFe don’t conflict with one another. One is hardly ever preferred over the other. Implementing Agile concepts is more a matter of context and goals.
Scrum is a very effective method for completing a project with a small crew. It is light on above and flexible and transparent. To function at a high level, those tiny team members must communicate frequently.
Nevertheless, Scrum is not a fantastic technique to manage a big business that manages several products and projects at once. It’s the tenacious Special Ops strategy for using iterative development to achieve specific targets quickly.
A more solid framework is required to manage the complexity, interdependencies, and various teams needed to operate at scale in order to prevent chaos. From a specialized boutique to assembly-line scale coordination, it is progressing.
Without middle-management level oversight carried out at the program level, with numerous products or projects under that umbrella, SAFe’s Agile Release Train cannot function on schedule. Additionally, at the top levels of the organization, particular portfolios are responsible for an even wider range of control.
SAFe limits Agile’s ability for dynamism by requiring greater rigidity and planning, but it does so for the right reasons. Overall, the puzzle’s constituent parts must fit together, and larger companies require a higher level of standardization to allow for resource flexibility and component compatibility.
What are the Strengths and Weaknesses of SAFe?
SAFe’s strengths include:
• Helps cross-functional teams collaborate more effectively
• Helps organizations achieve greater transparency
• Aligns all aspects of a project to the broader business goals
SAFe’s weaknesses include:
• Firstly, some believe the framework is not pure agile, because requires too much upfront planning and process definition
• Also takes more of a top-down approach rather than a team-based approach
Should You Use the Scaled Agile Framework?
SAFe is most well-liked by corporate organizations because many of its components concentrate on removing the typical difficulties teams encounter when scaling agile.
In other words, because SAFe takes a more prescriptive approach than, say, Disciplined Agile (DA), which offers more flexibility and customization but also requires an organization to fully understand the agile philosophy already, it might be a good option to bridge the gap if your company is just starting to make the switch to agile.
It is important to keep in mind, though, that SAFe’s top-down approach to decision-making and project management might undercut some of the fundamental agile characteristics, including shared ownership, adaptability, and less rigid roles, which may have initially drawn your team to agile.
Companies who adopted SAFe: Cisco
Cisco’s Subscription Billing Platform (SBP) project had independent design, development, test, and deployment teams that worked in sequence when it was first designed using the waterfall methodology. This method slowed down development, leading to longer release cycles, missed delivery deadlines, poor quality, and a lot of overtime.
Cisco implemented the Scaled Agile Framework (SAFe) and launched the capabilities, defects and fixes, and projects agile release trains on SBP. The plan was to work together to develop and test tiny enhancements for one SaaS component before sending them to the team in charge of system integration and testing.
Cisco completed the new SBP release on time and without using overtime. Because to enhanced team collaboration, defects were decreased by 40% compared to previous waterfall releases, and defect removal effectiveness increased by 14%.
Course Manual 8: Feature-Driven Development (FDD)
Feature-Driven Development (FDD) is an agile software development process that focuses on the customer and delivers tangible software results often and effectively. FDD in Agile promotes status reporting at all levels, which aids in monitoring development and outcomes.
Teams may update the project frequently using FDD and spot mistakes right away. Also, clients can always get knowledge and useful outcomes. Because it lessens confusion and rework, two renowned morale-killers in the development industry, FDD is a preferred technique among development teams.
FDD was created and improved by Jeff De Luca, Peter Coad, and others. It was first used in 1997 during a project for a Singapore bank. A second, 18-month project with 250 people was launched after the initial 15-month, 50-person initiative proved successful.
Since then, it has evolved into a practical strategy perfect for lengthy, complex projects searching for a straightforward yet thorough methodology. FDD can be a good option for software development teams looking for a structured, focused Agile methodology that can be scaled across the product organization and will deliver clear outcomes, even though Scrum and new variations of Agile are more widely recognized methods (especially outside of software development).
How is FDD Different from Scrum?
Although it is connected to Scrum, FDD is a feature-focused methodology (as opposed to a delivery-focused method). A fundamental component of FDD, features are to it what user stories are to Scrum: Little tasks that are, most significantly, valued by the client.
“During FDD, a feature should be delivered every 2-10 days – which differs from Scrum, in which sprints typically last two, but sometimes four, weeks.”
FDD emphasizes documentation more than other methodologies (including Scrum and XP), which also affects how meetings are used. Teams in Scrum normally meet every day; in FDD, teams rely more on documentation to transmit critical information and don’t meet as often.
Another significant distinction is how the end user is perceived. In FDD, the end user is the real user, whereas in Scrum, the end user is often the Product Owner.
How DoesFDD Work?
Five fundamental actions take place throughout FDD and are typically used in large-scale development projects:
• Develop overall model
• Build feature list
• Plan by feature
• Design by feature
• Build by feature
The first two phases create the general shape of the model, while the last three are repeated for each feature. The fourth and fifth steps of the FDD process, Design by Feature and Build by Feature, will get the majority (approximately 75%) of the effort.
All Agile teams, including those utilizing FDD, have as their top priority meeting the needs of their clients as rapidly and efficiently as possible.
The difference is that once a goal has been established, teams using FDD arrange their tasks according to features rather than according to project milestones or other measures of advancement.
How is a Feature Defined?
Every feature in FDD benefits the client, is significant, and produces something concrete to display. Also, the technique is dependent on its two-week cycle since corporations value speedy outcomes.
Stages of Feature-Driven Development
Stage 0: Gather Data
Like with all Agile techniques, the first step in FDD is to build a clear, common understanding of the target audience and their demands as well as to accurately comprehend the content and context of the project. Teams should try to understand as much as they can about the why, what, and for whom of the project they are going to start during this period (the next few steps will help clarify the how). You could think of this data collection as stage 0, yet it is an essential step. This is the research and thesis development stage, if product development were to be compared to writing a research paper.
The first designated stage in FDD, Building an Overall Model, can start once teams have a firm grasp on their objectives, the audience they are targeting, and their present (and possibly future) needs.
Step 1: Develop an overall model
The outline is created at this step, to continue the research paper metaphor. The team will create thorough domain models using the “thesis” (also known as the major goal) as a guide, which will then be combined into one overall model that serves as a basic framework of the system. Details will be provided as it progresses and the team gains knowledge.
Step 2: Build a features list
Make a list of the necessary features using the data gathered in the first stage. A feature is an output that the customer values. Create a list of features that you can finish in two weeks, keeping in mind that these features should be purposes or smaller goals rather than tasks.
Step 3: Plan by Feature
Now, tasks. Consider the difficulty of each feature and create a plan for the team to complete associated tasks. All team members should participate in the feature evaluation process throughout the planning phase, keeping in mind the viewpoint of each development stage. The sequence in which each feature will be implemented and the team members who will be given responsibility for each feature set will then be decided using the difficulty assessment.
The class owners, or specific developers allocated to each class, should also be identified at this stage. The conceptual guiding principles of each class in the developing feature are the responsibility of a different developer, and if modifications are needed to more than one class, cooperation between the owners of each class is required to implement the changes.
In addition, feature teams are equally crucial to FDD as class owners are. Certain roles are established in feature teams, and a range of perspectives are encouraged. As a result, design choices take into account various ideas and viewpoints.
Construction Phase
You go through the list of features in FDD’s design and build phase, one feature at a time.
Work is fundamentally incremental and iterative since it is done in two-week cycles, or iterations. The FDD wants you to split up features to match that rigorous two-week timetable.
Teams can be created and reorganized in FDD while keeping in mind the specifications of the things you’ll be building next. Choosing members for a particular feature team is often the lead programmer’s responsibility.
Step 4: Design by Feature
The feature that will be planned and built will be decided by the main programmer. In defining the feature priorities, he or she will also decide on the involved class owners and feature teams. While some members of the team may be focusing on framework, others may be working on technical design. The entire team does a design review at the conclusion of the design phase before continuing.
Step 5: Build by Feature
All the elements required to support the design are put into place in this step. Here, user interfaces are built, technical design components are built, and a feature prototype is made. The feature can be promoted to the main build after the unit has been tested, examined, and approved. Any feature that takes more than two weeks to develop and create is divided into smaller parts until it adheres to the two-week rule.
Similarities and Differences
The original domain model, up-front design and planning, as well as iterative and incremental execution, are all components of feature driven development. As a result, it is agile and architecture-centric.
It is agile in that it places a strong emphasis on addressing end-user demands, working with customers’ domain experts, and segmenting requirements into manageable features that provide commercial value.
Other than that, it is far less agile.
Overall, I’d venture to say that while FDD is a good step away from the waterfall methodology, it falls short of many widely accepted agile practices that are more effective at promoting shared responsibility, igniting and engaging everyone’s creativity, and deferring decisions to the last responsible moment.
Documentation
FDD is adamant about including meeting minutes, construction data, and choices and concerns that have come up into a knowledge system with the (design) documentation. It also insists on maintaining accurate and up-to-date documentation. As a result, it relies far more on documentation than the majority of agile techniques.
Hierarchy, top-down execution, and teams
With its use of traditional project management, hierarchical (line) management, and the chief architect and chief programmer responsibilities, particularly during the planning and design phases, FDD is hierarchical in nature.
Moreover, FDD does not aim to form long-term teams, in contrast to other agile frameworks. The lead programmer has control over team composition when teams form and break up around the features that will be produced next. Team members have little to no control over their coworkers.
Together, these facts indicate that FDD teams are not and cannot become self-managing or self-organizing, and that you won’t find teams conducting retrospectives that are heavily focused on their processes, collaboration, and interaction, which are crucial in many agile frameworks.
Dealing with change
It is feasible to halt the building process as FDD plans, designs, and constructs “by feature” and evaluate how to react to alterations in the new system’s environment, such as the entry of a new competitor into your market.
Because you would effectively have to redo the planning phase to decide which developed features to delete, which not-yet-finished features to remove, and which new features to add, FDD is more changeable than the waterfall model, but there is more waste than in other agile techniques. And that takes into account all the updates required to keep the documentation current.
Key Roles and Responsibilities
The project manager is in charge of the entire undertaking and employs conventional methods as opposed to agile ones.
The day-to-day operations are handled by the development manager. He or she serves as both a mentor for less experienced team members and the line manager for the developers.
The chief architect is in charge of the system’s overall design and directs the work of the developers and subject matter experts during the original and iterative design phases.
A seasoned developer, the chief programmer supports teams with analysis and design during the design and construction phases. He or she aids other developers and class owners in maintaining consistency in the code base’s implementation of software design principles. He or she might also oversee little development teams.
Any developer in charge of planning, creating, testing, and documenting a class that uses code to implement a specific portion of the domain object model is known as a class owner.
A subject matter expert is familiar with the customer’s business in general and the specific area that the new product (system) will support. He or she aids the development teams in comprehending how the firm functions and what it requires. He or she typically works for the client’s company.
Key Meetings, Cycles, Delivery Cadences
The original domain object model and feature list are created during the two-week Planning Phase.
Deliveries of work for testing throughout the Design and Construction phase are made once a week.
Every two weeks, customers receive new feature deliveries.
Reviews of performance and growth involve teams. For instance, during the building stage, round-table discussions are regularly held to examine codes.
Methods and Techniques
In comparison to other approaches, FDD is more structured when broken down into its five phases. This is mirrored in the strategies and tactics it promotes and employs.
Object-Oriented Design: It should come as no surprise that object-oriented design plays a significant role in feature driven development given that Peter Coad, a well-known object-orientation proponent and UML pioneer, is one of its founders.
Functionality and feature sets: Features are discrete components of a product’s functionality that the customer values. They are formulated in terms of action, outcome, and object, as in “Calculate the total of a sale.” Simply said, feature sets are collections of features.
Ownership of individual classes in programming: Each class or related group of functions in a program has a single owner who is in charge of the program’s functionality and quality.
Feature teams: In FDD, feature teams are dynamic; they are formed from class owners and disbanded as required by the features that will be built next.
Inspections: FDD makes use of design inspections and code inspections to stop problems from happening, or rather to find them before they do.
Extremely noticeable progress reports: FDD calls for a thorough and simple set of progress reports. It uses several milestones to reliably report feature progress and color-codes statuses for a simple, overarching view of project progress. The Parking Lot chart and the Feature Complete chart are two progress reports that are special to FDD.
Common Pitfalls
Due to hierarchical management and top-down design, the agile components of FDD may become overburdened.
Teams that are dynamically formed around class owners who are required for features frequently work against obtaining the advantages of a close-knit, stable team that supports one another.
The chief architect and programmer, as well as the project and development managers, are among the experienced individuals who FDD largely depends on. FDD is top-heavy in that regard, and smaller organizations with fewer workers may find it challenging to implement it successfully.
Conclusion
Long-term, complicated projects are best served by the pragmatic Agile technique known as “Feature-Driven Development.” It is a good option for development teams looking for a straightforward but structured Agile approach that is scalable and produces predictable outcomes.
Feature Driven Development Example
Pre-work is done before the development phase in feature driven development. The team and the developers must come to an understanding regarding the broad technical strategy, talk about the technology, vocabulary, take the appropriate testing steps, and establish a live environment.
The creation of a Mousebreaker is a typical example of Feature Driven Development. It’s a website for casual gaming that combined Kanban with Feature Driven Development. deliver a new website with a new codebase in a timely manner within 28 days. The main purpose of a user’s visit to the Mousebreaker website is to play flash games. The user’s ability to play games on the website was the initial feature.
This is manipulated by feature driven development, which reclassifies the requirements as features. These features are given priority in a backlog of work by the company’s owners and development team. Then, the developers deliver these functionalities in a way that gives businesses the greatest benefit.
Course Manual 9: Crystal
Crystal Agile Framework: What is the Crystal Method?
Crystal is an agile framework that puts people and their interactions before procedures and equipment. In other words, this framework is a natural extension of a fundamental principle expressed in the Agile Manifesto.
The two underlying principles of the Crystal Agile framework are:
• Teams can find ways on their own to improve and optimize their workflows
• Every project is unique and always changing, which is why that project’s team is best suited to determine how it will tackle the work
What is the History of the Crystal Method?
In 1991, Alistair Cockburn, who is recognized as one of the pioneers of agile, created the Crystal approach for IBM. Instead of concentrating on creating detailed, step-by-step development techniques that would be applicable to all teams working on any project, he made the decision to create policies for effective teamwork and communication. Cockburn’s Crystal method’s characteristics were therefore all centered on the team:
• Human-powered (meaning the project should be flexible and tailored to the needs and the preferred work modalities of people involved)
• Adaptive (meaning the approach uses no fixed tools but can be altered to meet the team’s specific needs)
• Ultra-light (meaning this methodology does not require much documentation or reporting)
What are the Strengths and Weakness of Crystal?
Crystal’s strengths include:
• Allows teams to work the way they deem most effective
• Facilitates direct team communication, transparency and accountability
• The adaptive approach lets teams respond well to changing requirements
Crystal’s weaknesses include:
• Lack of pre-defined plans can lead to scope creep
• Lack of documentation can lead to confusion
Should You Use Crystal?
Because it is built on the people involved in a project and is not reliant on any particular set of procedures or tools, the Crystal approach is one of the more adaptable agile frameworks. In that regard, it can be a practical practice for businesses that wish to provide their teams the freedom to work however they think is most productive.
However, it is crucial to keep in mind that because Crystal prioritizes direct team engagement around the software they are developing—and downplays the significance of documentation and reporting—other teams around the business may have less access to the team’s work.
Companies that focus on empowering their teams: Arby’s
Arby’s has a reputation for having highly engaged and satisfied employees. Even under difficult circumstances, Arby’s looks to its staff for support. Paul Brown, the CEO of Arby’s, asked his teams that worked in the restaurants what they would do to save the business during a trying period.
By doing this, Arby’s was able to empower their staff members while also gaining a greater understanding of and perspective on the frontline experience. Brown as a result made adjustments to enhance the client experience.
Through a number of initiatives, Arby’s keeps empowering their teams and placing a strong emphasis on the employee experience. Most recently, they launched the “better value and support Arby’s employees.” Arby’s Brand Champ program, which attempts to teach their personnel how to communicate with customers more effectively. Around 70,000 employees have been informed since the program’s inception that if they “take the time to understand Arby’s goals, Arby’s will try to understand theirs as well” When it comes to the employee experience, Arby’s goes above and beyond to make sure that their staff members not only succeed at work but also have the tools and support to realize their goals, whether they are for higher education or professional advancement.
The Framework
In contrast to more rigid frameworks like scrum, crystal encourages users to customize the structure for their particular situation since it acknowledges that various teams will perform differently depending on the size, importance, and priority of the project.
A small team, for instance, can maintain alignment through routine contact, necessitating less status reporting and documentation, compared to a large team, which is more prone to become out of sync and would benefit from a more formal approach.
Depending on how many people are participating in the project, these are categorized by color;
Methods of Crystal Family
Clearly Stated: a small team of 1-6 individuals Supports a contract with a fixed price and little room for negotiation; people-oriented; places little emphasis on the process or the physical products; calls for documentation Putting project safety first
• Crystal Yellow
– Small team size of 7-20
– Clear ownership of code areas. Code area ownership is defined so that if any changes required, then only the person who owns that code will be taking care of it.
– Feedback gets taken from the “Real Users”. Additionally, it eliminates further confusion which may occur due to indirect communication.
– Prefer accessible and direct communication. It reduces the need for too much documentation. Therefore, it becomes easy for the developer to understand his work.
– Mission statements are the goals which are defined and verified with the customer.
– Automated testing is used to resolve the bugs faster.
– Monthly improvement plans get set. Which includes making a to-do list and achieving it within the time.
• Crystal Orange
– Team size of 21 to 40
– The project lasts from 1-2 years
– Split up teams as per their functional skills
– Just like the agile method, follow incremental development
– A release is required every 3-4 months
– Every release is called “Increment”.
– Designed for medium size project
• Crystal Orange web
– Team size of 21 to 40
– Used in the Projects that have a continually evolving code base that is being used by the public
– It focuses on raising the minimal defect
Despite the fact that Crystal Orange and the Crystal Orange web are comparable, the Crystal Orange web deals with a number of programming-intensive efforts rather than a single project. The outcomes of these activities are incorporated into the code base and used by the programmers. But the process is still the same. It is not displayed separately in the graphic because of this.
• Crystal Red
– The traditional software development method gets followed for the team size of 40-80. In addition to that, the teams are formed and divided as the work required.
• Crystal Maroon
– It is for the team size 80-200. It is for large-sized projects. Moreover, the methods defined are different & as per the need of the software.
Above are the primary members of the Crystal family. However, for large size projects, there are two more methods.
Crystal Diamond and Crystal Sapphire:
These approaches are utilized for extremely important and big projects. Their personnel and techniques are chosen based on how crucial the project is. These initiatives are very important and run the risk of endangering human lives.
Process Flow
As seen in the following figure, the Cycle of Crystal standard procedure is comparable to Scrum:
This graph demonstrates that every project is completed in tiny episodes. The iterations (episodes) are planned. Functionality is planned and coded in advance of delivery in the following iteration.
• The same codebase can be used for the next iteration coding as well. That is called the Integration of that episode.
• After that, each iteration is delivered either daily or weekly.
• Once all the iterations finish, the integration of the project as a whole executes.
• Finally, after Integration and testing, the project delivery takes place.
7 Cycles of Crystal method are as follows:
1. The Project cycle:
A project cycle has the following three parts:
1. The Chartering activity: Firstly, the Chartering phase involves multiple activities. Developing an initial plan, creating and assigning Development teams, performing feasibility analysis. Some of the most important activities performed are.
• Build the core team: The definition and creation of the complete team occur in the charting phase. The decision of an Executive sponsor, a designer, a developer, and a key user takes place. After major roles are selected, 2/3 more people will be added to the teams.
• Exploring: In this phase, the developer and design team will be exploring all the solutions and will choose the best-suited solution for development.
• Shaping Methodology: After the discussion of all possible solutions, the Developers will finalize the methodology that they will follow for development.
• Initial Project Planning: After the finalization of the method, developers will sit with the rest of the teams and do the initial phase planning. Additionally, they will start designing the project accordingly.
2. Cyclic delivery: Secondly, the cyclic delivery has two phases, during which the
• Team updates and improves the release plan
• The development team implements a subsection of the requirements through one or more iterations.
• Integrated product delivery happens to actual users
• Lead developer reviews the project plan and adopted development methodology
3. Wrap Up: Lastly, this phase has the final activities. Product deployment occurs in a real user’s environment. After the implementation, post-deployment reviews and reflections take place in this phase.
2. The Delivery Cycle:
The delivery cycle is the measurement of progress toward delivery. It displays how the finished product was delivered. Depending on the magnitude of the job, it can take a week to three months or more. This cycle also provides two or more iterations in addition to the aforementioned.
3. The Iteration Cycle:
the estimating, developing, and testing unit. It might possibly change from one week to three months.
4. The Work Week/Day:
It is a unit that displays the entirety of a week’s worth of work.
5. Integration Period:
It is a unit that combines system testing, design, development, and integration. This time span can extend anywhere from a few hours to three days.
6. The Workday:
A unit that shows all the work done daily.
7. The Episode:
designing, writing, and testing a little segment of code (iteration). It can take a few minutes or several hours.
Crystal development vs other Scrum methods
In addition to XP, Scrum, ASD, FDD, and of course, Crystal, there are several agile approaches available. Choosing between several agile development models has perks and cons depending on how your team works.
In contrast to most agile methodologies, which aim to provide a one-size-fits-all solution, Crystal development emphasizes the premise that every project is different. Crystal techniques provide us the challenge of tailoring our procedures to take into account those special features, producing the greatest potential end result.
Key principles of the crystal agile framework
Seven principles that define a family are at the center of the crystal. All crystal techniques must include the first three; the remaining are optional and may be used as necessary.
#1: Frequent delivery
You should regularly provide code to your actual users. Without it, you risk creating a product that no one wants.
#2: Reflective improvement
Consider your past actions and the reasons behind them. Think about it collectively and decide how to make it better moving forward.
#3: Osmotic communication
Co-location, or having teams in the same physical place, was important in Cockburn’s opinion because it allowed information to spread among team members as if by osmosis.
#4: Personal safety
Team members should feel comfortable discussing ideas openly without worrying about being mocked. In a crystal team, there are no bad ideas or incorrect replies.
#5: Focus on work
Each team member should be aware of and capable of doing their next task. This necessitates unambiguous communication and, when necessary, documentation.
#6: Access to subject matter experts and users
When necessary, team members should have access to input from actual users and subject matter experts.
#7: Technical tooling
Cockburn advocated for development teams to have access to tools for continuous deployment, automated testing, and configuration management as early as the 1990s. This implies that flaws and mistakes can be swiftly detected without human involvement.
Course Manual 10: Dynamic Systems Development Method (DSDM)
The DSDM Philosophy, Principles, and Project Variables
The DSDM Philosophy
According to the DSDM philosophy, every project must be in line with clearly stated strategic goals and concentrate on providing early delivery of substantial benefits to the company.
This is accomplished when all parties involved:
1. Understand and buy into the business vision and objectives
2. Are empowered to make decisions within their area of expertise
3. Collaborate to deliver a fit for purpose business solution
4. Collaborate to deliver to agreed timescales in accordance with business priorities
5. Accept that change is inevitable as the understanding of the solution grows over time
The DSDM concept is underpinned by eight principles that help develop the attitudes and actions required to make the philosophy real.
Four Ps provide support for the principles:
• people (with defined roles and responsibilities),
• an agile process (enabling an iterative and incremental life cycle to shape development and delivery),
• clearly described products,
• and recommended practices to help achieve the optimum results.
The DSDM Principles
The eight DSDM principles help the team acquire the attitude and mindset necessary to deliver consistently while maintaining flexibility, bringing the agile values to life.
Principle 1 – Focus on the Business Need
The ultimate project aim of delivering what the business needs to be delivered when it needs to be delivered should be considered when making every choice during a project.
Principle 2 – Deliver on Time
A project’s goal should be to deliver a solution on time, and this is frequently the single most
crucial success component.
Principle 3 – Collaborate
Teams are able to execute at a level that is higher than the sum of their individual parts thanks to collaboration, which promotes greater knowledge, greater speed, and shared ownership.
Principle 4 – Never Compromise Quality
The level of quality that will be given is decided upon up front in DSDM. The standard of quality should be the goal for all effort; nothing more and nothing less.
Principle 5 – Build Incrementally from Firm Foundations
The DSDM recommends first comprehending the breadth of the business problem that needs to be solved and the suggested solution, but not in such detail that an unduly in-depth analysis of the requirements paralyzes the project.
Principle 6 – Develop Iteratively
To encourage prompt input, DSDM combines iterative and incremental development, regular demonstrations, and thorough assessment. The team can come to a precise business answer by accepting change as a necessary component of this evolutionary process.
Principle 7 – Communicate Continuously and Clearly
Project failure is frequently attributed to poor communication as the primary factor.
The goal of DSDM practices is to enhance team and individual communication effectiveness.
Principle 8 – Demonstrate Control
The creation of Management Foundations and Timebox Plans, together with the usage of clearly defined Timeboxes with frequent review points, are all meant to make it easier for the Project Manager and the rest of the project team to adhere to this approach.
The Project Variables
The characteristics and content of the solution are fixed in the classic project management method (left-hand graphic), but time and cost are variable.
More resources are frequently added (which increases the cost) and the delivery date is extended if the project veers off course (which changes the time).
Nevertheless, adding resources to a project that is already behind schedule frequently causes it to be much further behind schedule, and missing a deadline may be terrible for business and frequently harm credibility.
Under such strain, quality frequently degrades because of the introduction of ill-considered concessions, the elimination of crucial quality control procedures, or the reduction of testing.
After the conclusion of the Foundations phase, the project management strategy used by DSDM (right-hand graphic) fixes time, cost, and quality. Also, by changing the characteristics that must be given (the requirements), contingency is controlled. Lower priority requirements are dropped or postponed when needed, with the full support of the business stakeholders, in accordance with MoSCoW priorities.
The DSDM Process Model
The five phases of the DSDM life cycle are depicted below.
The Feasibility and Business Study
The problem is identified during the feasibility and study phase, and the technical viability of the desired application is confirmed. The application’s suitability for the Rapid Application Development (RAD) approach is also examined.
Development doesn’t proceed until and until the RAD is determined to be a valid strategy for the target system.
Functional Model Iteration
The primary goal of this stage is to iteratively create the prototype while obtaining user feedback to reveal the intended system’s requirements.
The prototype is improved by showing it to the user, listening to their comments, and implementing the modifications. Until a certain component of the functional model is decided upon, this cycle is typically repeated two or three times.
A functional model made up of an analysis model and certain software components with significant functionality is the result of this phase.
Design and Build Iteration
During this stage, it is made certain that the prototypes are adequately and correctly engineered to fit their operational environment.
The functional modeling-generated software components are progressively improved until they meet a high level.
Hence, the two phases can carry on concurrently. This phase results in a tested system that is prepared for implementation.
Implementation
The last and last development stage in this process is implementation.
During this phase, the system is operationalized and the users are trained.
Following this step, there are four options, as shown in the following diagram:
• Everything was delivered as per the user demand, so no further development is required.
• A new functional area was discovered, so return to the business study phase and repeat the whole process.
• A less essential part of the project was missed out due to time constraints. So development returns to the functional model iteration.
• Some non-functional requirements were not satisfied, so the development returns to the design and build phase.
Products Produced in the DSDM Process and Their Purpose
A group of products to be taken into account as the project moves forward are described in the DSDM Agile Project Framework. These deliverables include the solution itself, anything developed to support its evolution, and anything necessary to support project governance and control. The solution itself serves as the project’s primary delivery.
DSDM recognizes two different product types:
• Evolutionary products evolve over time. They typically, but not always, span a number of project phases and may be baselined more than once during that time.
• Milestone products are created in a phase and typically fulfil a specific purpose within that phase as a checkpoint or to facilitate governance processes.
The Techniques Used in DSDM, Benefits and Limitations
The following strategies and procedures set DSDM apart from other system development approaches.
Timeboxing: DSDM follows rigorous deadline guidelines. To do this, the project must be divided into smaller components, each of which must have a set price tag and deadline. Requirements are prioritized to navigate this. Lowest priority criteria are dropped if time or funds are running low. Then, a completed project is made up of simply the absolute necessities.
MoSCoW: This is the hierarchy of importance used to rate items from most important to least important. Must Have, Should Have, Could Have, and Won’t Have are the groupings for prioritization. All of these competing deliverables, which are frequently generated at the same time, are facilitated by configuration management.
Modelling and Iterative Development: With modeling, various project components can be visualized along the route. By offering frequent feedback and putting improvement into practice, this helps to present each item as it is being developed and allows for iterative development.
Prototyping: Prototyping is crucial to test-run the project at an early, conceptual level, similar to many agile approaches. It is a method for outlining the fundamental operations, spotting obvious flaws, and enabling users to test the software.
Workshops: Users and stakeholders are included in the discussion of the requirements, problems, outcomes, and testing. From the start, DSDM depends heavily on human engagement. For DSDM, testing is crucial since it verifies the quality of the results.
DSDM Roles
There will be a list of positions that need to be filled in any agile systems development. DSDM is equivalent. These are the crucial roles in any DSDM ecosystem, according to their manual.
1. Executive Sponsor (the “Project Champion”) – Someone will be assigned to this position by the user organization and/or the client. Also, they have the authority to allocate money and resources as necessary. While making decisions, they have the “ultimate say.”
2. Visionary – The Visionary kicks off the project by settling on the highest priority requirements early on and directing the team based on these, armed with clear objectives and a grasp of the user business.
3. Ambassador User – An ideal “test user” is one who gives the project the viewpoint of the user base. They develop into a crucial source of input during the entire procedure.
4. Advisor User – Another type of user who should contribute critical perspectives to the current project. They might have special knowledge or other skills that make them the best choice.
5. Project Manager – Somebody who oversees a project as a whole is a project manager.
6. Technical Co-ordinator – They are in charge of every technical element quality control and will create the system architecture.
7. Team Leader – The team’s captain is in charge of organizing and encouraging cooperation.
8. Solution Developer – Model the system, generate the deliverable codes, and build prototypes while navigating any system constraints.
9. Solution Tester – Tests the product, noting any issues with documentation and comments. After corrections are made, they also retest.
10. Scribe – Keeps track of all requirements, agreements, decisions, and other information that is relevant to the project’s progress.
11. Facilitator – They are in charge of inspiring and organizing the workshop to maintain steady and constant progress. They need to be an expert communicator who can keep everyone on task.
12. Specialist Roles – These are positions filled by experts in their field or sector who provide additional help as needed for the project. These may differ from one project and one team to another. This type of role could also be a system integrator, business architect, or quality manager, among others.
Similarities and Differences: Scrum vs DSDM
Although Scrum and DSDM are very similar, they also differ significantly in a few key ways.
DSDM, for instance, categorizes activities into the “engineering activity” (also known as the development phase) and the “emerging solution” (AKA the output). In contrast, the output in Scrum is referred to as the “possibly releasable increment.”
Both approaches have lists of smaller jobs that are finished in accordance with strict timeframes. Both approaches lead to a project’s completion, which Scrum signals when it reaches the “Definition of Done.” A crucial distinction between Scrum and DSDM is that when this “Definition of Done” is reached, the project does not have a clear end point.
The project’s Foundation Phase is the predetermined time period in DSDM during which the definition of work (and accomplished work) is established. This occurs rather early on, which occasionally results in the planning process being tainted by assumptions. In order to take the assumptions into account, the definition of “completed” work must be routinely revised during the project lifespan.
The problem is that team leaders steer clear of Big Design Up-Front (BDUF), which is more of a Waterfall Methodologies trait than an Agile one.
Why Choose DSDM as Your Agile Approach
DSDM works with projects rather than just the creation and delivery of a product, which gives it a broader focus than most other agile methodologies (typically software).
DSDM has a long history of successfully delivering agile projects in many corporate settings. It has also demonstrated full scalability, operating well in settings that are highly regulated, huge and complex, and small and basic firms.
But, DSDM’s project focus really shines when it comes to developing new, complicated products that require multiple teams and more than a few months to complete.
As an illustration, consider a system that combines data from various independent solutions to give you the uniform view of performance required for efficient executive dashboards throughout your firm.
You can lower the risk of these endeavors with the aid of DSDM.
Moreover, DSDM can be utilized to support an already-in place internal agile methodology. To complement Scrum’s team-focused product development method, for instance, DSDM is frequently utilized to offer the full “project” focus.
Get Agile with DSDM
The dynamic method that fully and effectively aids you in navigating the complicated and dynamic business of building a software product is the dynamic system development method.
By using DSDM, you may execute in a regulated manner while working toward a specific business result. Your employees will provide value promptly and to the expected level of quality.
Workshop Exercises
Agile Practices Exercises
01. Agile Challenges: Explain in your own words how this process will directly impact upon your department?
02. Extreme Programming (XP): Explain in your own words how this process will directly impact upon your department?
03. Kanban: Explain in your own words how this process will directly impact upon your department?
04. Scrum: Explain in your own words how this process will directly impact upon your department?
05. Disciplined Agile Delivery (DAD): Explain in your own words how this process will directly impact upon your department?
06. Lean Development: Explain in your own words how this process will directly impact upon your department?
07. Scaled Agile Framework (SAFe): Explain in your own words how this process will directly impact upon your department?
08. Feature-Driven Development (FDD): Explain in your own words how this process will directly impact upon your department?
09. Crystal: Explain in your own words how this process will directly impact upon your department?
10. Dynamic Systems Development Method (DSDM): Explain in your own words how this process will directly impact upon your department?
SWOT & MOST Analysis Exercises
01. Undertake a detailed SWOT Analysis in order to identify your department’s internal strengths and weaknesses and external opportunities and threats in relation to each of the 12 Agile Practices processes featured above. Undertake this task together with your department’s stakeholders in order to encourage collaborative evaluation.
02. Develop a detailed MOST Analysis in order to establish your department’s: Mission; Objectives; Strategies and Tasks in relation to Agile Practices. Undertake this task together with all of your department’s stakeholders in order to encourage collaborative evaluation.
Project Studies
Project Study (Part 1) – Customer Service
The Head of this Department is to provide a detailed report relating to the Agile Practices process that has been implemented within their department, together with all key stakeholders, as a result of conducting this workshop, incorporating process: planning; development; implementation; management; and review. Your process should feature the following 12 parts:
01. Agile Challenges
02. Extreme Programming (XP)
03. Kanban
04. Scrum
05. Disciplined Agile Delivery (DAD)
06. Lean Development
07. Scaled Agile Framework (SAFe)
08. Feature-Driven Development (FDD)
09. Crystal
10. Dynamic Systems Development Method (DSDM)
Please include the results of the initial evaluation and assessment.
Project Study (Part 2) – E-Business
The Head of this Department is to provide a detailed report relating to the Agile Practices process that has been implemented within their department, together with all key stakeholders, as a result of conducting this workshop, incorporating process: planning; development; implementation; management; and review. Your process should feature the following 12 parts:
01. Agile Challenges
02. Extreme Programming (XP)
03. Kanban
04. Scrum
05. Disciplined Agile Delivery (DAD)
06. Lean Development
07. Scaled Agile Framework (SAFe)
08. Feature-Driven Development (FDD)
09. Crystal
10. Dynamic Systems Development Method (DSDM)
Please include the results of the initial evaluation and assessment.
Project Study (Part 3) – Finance
The Head of this Department is to provide a detailed report relating to the Agile Practices process that has been implemented within their department, together with all key stakeholders, as a result of conducting this workshop, incorporating process: planning; development; implementation; management; and review. Your process should feature the following 12 parts:
01. Agile Challenges
02. Extreme Programming (XP)
03. Kanban
04. Scrum
05. Disciplined Agile Delivery (DAD)
06. Lean Development
07. Scaled Agile Framework (SAFe)
08. Feature-Driven Development (FDD)
09. Crystal
10. Dynamic Systems Development Method (DSDM)
Please include the results of the initial evaluation and assessment.
Project Study (Part 4) – Globalization
The Head of this Department is to provide a detailed report relating to the Agile Practices process that has been implemented within their department, together with all key stakeholders, as a result of conducting this workshop, incorporating process: planning; development; implementation; management; and review. Your process should feature the following 12 parts:
01. Agile Challenges
02. Extreme Programming (XP)
03. Kanban
04. Scrum
05. Disciplined Agile Delivery (DAD)
06. Lean Development
07. Scaled Agile Framework (SAFe)
08. Feature-Driven Development (FDD)
09. Crystal
10. Dynamic Systems Development Method (DSDM)
Please include the results of the initial evaluation and assessment.
Project Study (Part 5) – Human Resources
The Head of this Department is to provide a detailed report relating to the Agile Practices process that has been implemented within their department, together with all key stakeholders, as a result of conducting this workshop, incorporating process: planning; development; implementation; management; and review. Your process should feature the following 12 parts:
01. Agile Challenges
02. Extreme Programming (XP)
03. Kanban
04. Scrum
05. Disciplined Agile Delivery (DAD)
06. Lean Development
07. Scaled Agile Framework (SAFe)
08. Feature-Driven Development (FDD)
09. Crystal
10. Dynamic Systems Development Method (DSDM)
Please include the results of the initial evaluation and assessment.
Project Study (Part 6) – Information Technology
The Head of this Department is to provide a detailed report relating to the Agile Practices process that has been implemented within their department, together with all key stakeholders, as a result of conducting this workshop, incorporating process: planning; development; implementation; management; and review. Your process should feature the following 12 parts:
01. Agile Challenges
02. Extreme Programming (XP)
03. Kanban
04. Scrum
05. Disciplined Agile Delivery (DAD)
06. Lean Development
07. Scaled Agile Framework (SAFe)
08. Feature-Driven Development (FDD)
09. Crystal
10. Dynamic Systems Development Method (DSDM)
Please include the results of the initial evaluation and assessment.
Project Study (Part 7) – Legal
The Head of this Department is to provide a detailed report relating to the Agile Practices process that has been implemented within their department, together with all key stakeholders, as a result of conducting this workshop, incorporating process: planning; development; implementation; management; and review. Your process should feature the following 12 parts:
01. Agile Challenges
02. Extreme Programming (XP)
03. Kanban
04. Scrum
05. Disciplined Agile Delivery (DAD)
06. Lean Development
07. Scaled Agile Framework (SAFe)
08. Feature-Driven Development (FDD)
09. Crystal
10. Dynamic Systems Development Method (DSDM)
Please include the results of the initial evaluation and assessment.
Project Study (Part 8) – Management
The Head of this Department is to provide a detailed report relating to the Agile Practices process that has been implemented within their department, together with all key stakeholders, as a result of conducting this workshop, incorporating process: planning; development; implementation; management; and review. Your process should feature the following 12 parts:
01. Agile Challenges
02. Extreme Programming (XP)
03. Kanban
04. Scrum
05. Disciplined Agile Delivery (DAD)
06. Lean Development
07. Scaled Agile Framework (SAFe)
08. Feature-Driven Development (FDD)
09. Crystal
10. Dynamic Systems Development Method (DSDM)
Please include the results of the initial evaluation and assessment.
Project Study (Part 9) – Marketing
The Head of this Department is to provide a detailed report relating to the Agile Practices process that has been implemented within their department, together with all key stakeholders, as a result of conducting this workshop, incorporating process: planning; development; implementation; management; and review. Your process should feature the following 12 parts:
01. Agile Challenges
02. Extreme Programming (XP)
03. Kanban
04. Scrum
05. Disciplined Agile Delivery (DAD)
06. Lean Development
07. Scaled Agile Framework (SAFe)
08. Feature-Driven Development (FDD)
09. Crystal
10. Dynamic Systems Development Method (DSDM)
Please include the results of the initial evaluation and assessment.
Project Study (Part 10) – Production
The Head of this Department is to provide a detailed report relating to the Agile Practices process that has been implemented within their department, together with all key stakeholders, as a result of conducting this workshop, incorporating process: planning; development; implementation; management; and review. Your process should feature the following 12 parts:
01. Agile Challenges
02. Extreme Programming (XP)
03. Kanban
04. Scrum
05. Disciplined Agile Delivery (DAD)
06. Lean Development
07. Scaled Agile Framework (SAFe)
08. Feature-Driven Development (FDD)
09. Crystal
10. Dynamic Systems Development Method (DSDM)
Please include the results of the initial evaluation and assessment.
Project Study (Part 11) – Logistics
The Head of this Department is to provide a detailed report relating to the Agile Practices process that has been implemented within their department, together with all key stakeholders, as a result of conducting this workshop, incorporating process: planning; development; implementation; management; and review. Your process should feature the following 12 parts:
01. Agile Challenges
02. Extreme Programming (XP)
03. Kanban
04. Scrum
05. Disciplined Agile Delivery (DAD)
06. Lean Development
07. Scaled Agile Framework (SAFe)
08. Feature-Driven Development (FDD)
09. Crystal
10. Dynamic Systems Development Method (DSDM)
Please include the results of the initial evaluation and assessment.
Project Study (Part 12) – Education
The Head of this Department is to provide a detailed report relating to the Agile Practices process that has been implemented within their department, together with all key stakeholders, as a result of conducting this workshop, incorporating process: planning; development; implementation; management; and review. Your process should feature the following 12 parts:
01. Agile Challenges
02. Extreme Programming (XP)
03. Kanban
04. Scrum
05. Disciplined Agile Delivery (DAD)
06. Lean Development
07. Scaled Agile Framework (SAFe)
08. Feature-Driven Development (FDD)
09. Crystal
10. Dynamic Systems Development Method (DSDM)
Please include the results of the initial evaluation and assessment.
Program Benefits
Information Technology
- Agile IT processes
- Improved value delivery
- Decreased defects
- Continuous improvement
- Modernized infrastructure
- Re-tooled staff
- Increased morale
- IT Business partnership
- Meaningful metrics
- Effective sourcing
Management
- Decreased costs
- Aligned strategies
- Servant leadership
- Clarified priorities
- Improved effectiveness
- Improved transparency
- Reduced risk
- Measurable results
- Satisfied customers
- Vendor partnerships
Human Resources
- Empowered teams
- Servant leaders
- Re-tooled staff
- Improved teamwork
- Enhanced collaboration
- Improved performance
- Reduced turnover
- Improved loyalty
- Leadership development
- Employee development
Client Telephone Conference (CTC)
If you have any questions or if you would like to arrange a Client Telephone Conference (CTC) to discuss this particular Unique Consulting Service Proposition (UCSP) in more detail, please CLICK HERE.