More and more organizations are realizing the benefits of running projects using Scrum, XP, and/or Kanban at the individual team level
Whether you're doing "Agile" or not, you can always learn more!
The implementation of Agile requires an understanding that changing the status quo is a long-term, organization-wide, major initiative that will take significant resources to accomplish. However, the rewards of using Agile make the investment worthwhile.
Even companies that are successfully doing "Agile Like" could still benefit from a more extensive understanding of how Agile can be best implemented to generate maximum return on investment.
At Eliassen Group we are confident that we can help your company excel substantially and profit from the application of Agile!
What exactly is "Agile?" What are the specific principles and practices that are present in an Agile organization? When we say we have an "Agile" organization are we really just saying that we're more nimble than we used to be? Actually, you may have a very nimble organization that is not "Agile" at all! This session lays out exactly what it means to be Agile and gives concrete examples of some of the typical hallmarks of a truly Agile organization.
Learn Agile and have fun at the same time! Everything you learn will be via real Agile activities that you do as a team. You’ll form into cross-functional teams, invent your own software product to use as an example for the activities, and become completely immersed in the principles and practices of Agile. There’s no actual coding, no computer required, it’s just fun activities that anybody can do that show you what being on an Agile team is really like. For anybody involved in development: management, product managers, business analysts, designers, developers, testers, DBAs, technical writers, project managers, etc. Bring an existing team or create a team with other participants during the session.
Throughout the session, you will also have the experience of seeing a demonstration of self-organization on a large scale.
These days, more and more organizations wish to run some projects using an Agile methodology such as Scrum, Kanban, or XP. But the problem is, the organizational structure, policies, procedures, governance, controls and even contracts are purpose built to support and reinforce traditional methodologies while unintentionally impeding and discouraging the use of Agile methodologies. If implementing Agile is approached as a minor initiative and “just another methodology option” it is unlikely to survive in this environment. Unlike most other innovations in the IT/software arena, hitting the sweet spot of Agile requires changes to how the company does business as well as mindset and cultural changes.
Fortunately, there are strategies and tactics that can be applied to enable Agile to succeed within a Waterfall company. That success can then be leveraged to motivate the changes required to hit the sweet spot of Agile and thus the significant benefits that Enterprise Agility provides. The two main strategies for Agile success in a Waterfall world are to wrap the Agile team in a Waterfall-friendly translation layer and to create a safe zone for Agile teams where they can survive and thrive.
As Agile methods have become common, adoption within a single development team is fairly straightforward. Scaling and measuring Agile methods with multiple teams often proves much more challenging. This session covers the keys to success in scaling and measuring Agile methods beyond a single team.
One of the fundamentals of Agile is self-organizing teams. The Agile community has discovered a number of techniques that are useful for helping a team to become and stay self-organizing. In this session you will form into cross-functional self-organizing teams and learn these techniques by doing real Agile activities together.
Many, or even most, Agile Transformations are run by a single Agile Coach as a traditional project. But when you try to do this on the extreme scale, you learn some things that you might not otherwise learn. In this session, you will learn how you can apply lessons learned at the extremes to any coaching engagement whether you are the only coach in an engagement or one coach on a team of coaches. The most valuable lesson is that there is a huge difference between coaching Agile and being Agile.
In an engagement that is helping a large financial institution perform an Agile Transformation, the coaching team has grown from 1 coach to 20. In the beginning, the coaches were acting as individual coaches each working with their assigned teams. Everything seemed to be going just fine, just like any other engagement with a handful of coaches. As the team grew to 20 coaches for hundreds of teams and thousands of people, the number of problems in the coaching team grew as well. The funny thing was... the problems all started to sound the same as any other traditional development team. And that was the "aha!" moment. When you put a bunch of head chefs in the kitchen, you get huge problems. Agile to the rescue!
It turns out that an Agile Transformation project is just as amenable to being run as an Agile project as the software projects that it is attempting to transform. Not only does this produce breakthrough results, it also has the interesting side effect of providing an amazing opportunity for self-evaluation and growth for the Agile Coaches. The coaches learned more about Agile and themselves in a short span of time than one would normally learn over the course of years.
A common starting place for Agile is implementing the process side of Agile via Scrum, Kanban, or a similar Agile methodology. Most organizations get good results with this approach, but after a while it starts to feel like something is missing. A good next step is to start looking into the technical practices.
When layered into an existing Agile methodology, these technical practices make the overall process easier to follow and can increase the benefits of Agile.
While Agile can produce modest gains in operational efficiency, its primary benefit comes from gains in business value creation. Maximizing business value creation requires changing how business is done and applying the principles and values of Agile throughout the Enterprise. There are many widely used Agile frameworks such as Scrum, XP, and Kanban, but these frameworks primarily contain guidance for only a single isolated team and do not provide guidance for creating an Enterprise Agile ecosystem.
This session will address this problem by exploring the concept of “Enterprise Agility.” Enterprise Agility is about applying the principles and values of Agile to create an ecosystem that embraces and supports Agile throughout the Enterprise.
There are many widely used team-based Agile solutions such as Scrum, XP, and Kanban but there are few similar solutions at the multi-team Enterprise level. The Enterprise Agility Model provides guidance for achieving Enterprise Agility based on the shared experience of many organizations and practitioners.
The Enterprise Agility model is based on the principles and values of the Agile Manifesto as well as the principle of “The Simplest Thing That Could Possibly Work.” It is contained in a short and simple document much like the Scrum Guide, a diagram that visually describes the interaction between the practices, and a spreadsheet for measuring Agile maturity at both an organizational and per-team level. This session introduces the model, provides a tour through the practices, and explains how the Enterprise Agile Maturity Matrix works.
The term "Agile" can mean different things to different people. That's because the word "Agile" is simply an adjective that refers to anything that supports the values and principles of the Agile Manifesto. Agile itself is not a specific methodology. The Agile community has created many practices and methodologies that can be described as "Agile," including Scrum, Kanban, XP, Continuous Integration, TDD, and much more. Thus, one person's experience of "Agile" may be Scrum with XP and another's might be Kanban and TDD.
This session will take people through the Enterprise Agile Maturity Matrix with interactive exercises that will help the attendees find out where their Agile values and experiences align and contrast. This knowledge will help participants emphasize their common ground and get differences out in the open so that they can be acknowledged and resolved.
Traditionally, many organizations have measured their software development efforts solely in terms of process efficiency and cost. When teams introduce Agile methods, they are suddenly able to measure their efforts from a broader business perspective - such as impact to the top and bottom line. This session discusses how to measure and optimize the economics of your software development, make economics-based decisions, measure and reduce the cost of delay, gauge the full cost of development within an Agile environment, and discover and validate the value of your user stories.
More and more organizations are realizing the benefits of running projects using Scrum, XP, and/or Kanban at the individual team level. Unfortunately, that typically means that in a 12-24 business idea to production timeframe, the “Agile” part may only be a 1-3 month “construction” phase with rigid controls in place that all but eliminate most of the benefit of Agile.
The root cause of this issue is that the whole organization is purpose-built to support and reinforce traditional methodologies while unintentionally impeding and discouraging the use of Agile methodologies. This is reflected in the organizational structure, physical location of people, the physical workplace, policies, procedures, governance, SDLC, contracts, vendors, belief systems, compensation, software tools, funding model, metrics, and more. A common belief is that all of these are set in stone and that Agile will need to fit in to this existing framework. As a result, many Agile adoptions eventually regress as the effort of working around the existing framework overwhelms the enthusiasm of the Agile evangelists. Unlocking the full power of Agile requires an understanding that changing the status quo is a long-term, organization-wide, major initiative that will take significant resources to accomplish. Such an initiative will only be undertaken if the rewards are significantly greater than the cost. In this session, you will learn about the true barriers to Agile adoption; the surprising and significant financial benefits of organization-wide Agile transformation; and the Kotter Change
While Agile can produce modest gains in operational efficiency, its primary benefit comes from gains in business value creation. Maximizing business value creation requires changing how business is done.
Note: versions of this session for an all business leader or all IT leader audience are also available.
Culture is the shared beliefs and behaviors of an organization. There is organization-wide culture and culture specific to functional areas including business, architecture, PMO, developers, QA, infrastructure, and management. In addition, all of this is set against the backdrop of 40+ years of software development and IT industry culture.
Agile brings a new set of beliefs and behaviors which may either reinforce the organization's existing culture, or create an opportunity to consider new possibilities. Agile also brings with it new practices, techniques, and software tools that support a shift in culture and can help to ease any potential conflict.
This session will examine the kinds of cultural and behavioral changes that Agile can bring, the benefits of those changes, and how to move towards a more Agile supportive culture. Specifically, we'll look at the role of culture in the following areas: raising impediments; long standing cross-functional teams; self-organization; frequent business and development interaction; breaking down silos; and managing, measuring, and compensating people.
Organizations are looking to reduce their time from idea to delivery more than ever before. Some organizations are able to go from idea to delivery in days and can deliver a hundred changes in a single day! Continuous Delivery (CD) is an emerging discipline for realizing these kinds of benefits. It isn’t easy to get to CD, but the significant business benefits make it worth the effort. This session will provide an overview of what Continuous Delivery is, the tools needed to implement it, and justification for making the investment.
As you scale Scrum across your enterprise, you will find that synchronizing the work of interdependent Scrum teams in a large program is a huge challenge. The most successful multi-team programs gravitate towards many practices and principles associated with Kanban. You can accelerate that process by learning from the experiences of five companies with very large multi-team Agile programs ranging from 20 teams to 150 teams.
This session will introduce Kanban from a Scrum perspective, show how the Lean practice of “One Piece Flow” is the key to both, and get into the nuts and bolts of specific practices and concepts from Kanban that can be adopted by an existing multi-team Scrum program. Along the way we will also see how this can significantly improve economic outcomes and employee satisfaction.
Every day, across a wide variety of software and IT organizations, people are working in an unhealthy environment. An unhealthy work environment has become so systemic, so ingrained, and so accepted as "business as usual" or "the culture around here" that it is effectively invisible. In the software industry we casually talk about "death marches" and how people that give up their vacations, weekends, and special events at their kid's schools are "real team players." We routinely set ridiculous deadlines that nobody believes in to "motivate" people into "giving it their all." And for what? Is a little extra bonus money worth the broken relationships, lost time with your children, high stress, guilt, unhappiness, and impact on health?
Unfortunately, one of the reasons that Agile adoptions fail is that implementing the principles and values of the Agile Manifesto requires breaking the deeply ingrained habits that lead to an unhealthy work environment. It is time to do more than just offer the solution of Agile development, it is time bring the subject to light and provide ways to counteract the behaviors that lead to an unhealthy work environment. Who is to blame? Is it a certain personality type or role? No. The root cause is not a person; it is the practices and organizational structures of traditional development itself. It is the system, not the people. Truly addressing the problem means changing the practices and organizational structures to support a healthy work environment. But the path to change starts with awareness and coping mechanisms. In this session, participants will share their stories, learn ways to peacefully and constructively counteract the unhealthy behaviors, and come up with new countermeasures.
When adopting Agile, iteration planning is often the only “Agile” planning adopted. For Agile to reach its full potential, the full planning cycle needs to be adapted to Agile. This session will show how to adopt Agile planning methods from initial business idea all the way to the release. Topics include: planning, funding, and prioritizing by Minimum Viable Increments (MVIs); creating MVIs; Kanban for Product Management; and large scale release planning and tracking.
As a manager, you’ve heard a lot about the benefits of self-organizing teams, but you’re not sure where to start, and you suspect self-organization may lead to chaos. You could just take a leap of faith, set self-organization as a goal and then look for ways to achieve self-organization. But there is another way.
We’ll cover self-organization from the bottom up using concrete examples of twelve widely adopted Agile practices: user stories, story points, product owner, product backlog, standup meetings, whole teams, collocation, assignment and estimation of tasks by team members, short iterations, Scrum master, burn-up charts, and retrospectives. You’ll learn how each practice contributes to self-organization by reducing and/or redistributing traditional management activities. These practices also help to reduce the temptation to get wrapped up in the details; provide a framework for delegation, communication and coordination; encourage team ownership, commitment and accountability; and create management artifacts that are appreciated by all.
The inevitable question that results from talking about self-organization is “what does a manager do in an Agile workplace?” We’ll wrap up with a group exercise that not only answers that question but also shows that Agile provides more leverage for managers to use the skills they already have.
Putting User Stories into business value order is a key tenet of Agile, but that's just the first step. There's much more value to be extracted from your user stories using specific story splitting techniques combined with reducing cycle time. By splitting user stories you can separate the gold from the dirt as well as reduce the cost of implementation. This session will cover a variety of methods for splitting user stories including the split by "create/read/update/delete" method, the split by acceptance test method, and the split by value method. These techniques can produce even more value when combined with frequent grooming, and Kanban flow which will also be covered.
Sign Up For A Lunch And Learn!