Real Agile in the AI Era-30X Faster with AI Integrated Teams

Where "Agile" begins.

We layout here the simple truth of where the understanding of the "Agile" way of doing things successfully begins. Many organizations send one or two individuals off on a two-day course and then expect them to come back and turn the organization around. This absolutely does not work.

There is a level of understanding that is required for this concept of "Agile" to work within the organization. It does not come from the few taking a crash course in an Agile Framework.

We emphasize in this topic that the success to be achieved by moving to this "Agile" way of thinking begins "between the ears" of the leadership of an organization.

Watch, listen, learn, understand, and enjoy.

We are Agile!

Agile Defined By One Word

When we begin to examine the word "Agile" and do an in-depth analysis, we realize that Agile is not a "Methodology" or "Framework", but something much different.

Yes, we use Frameworks and processes to achieve this thing called "Agility", but in themselves, they are not going to make us Agile.

In this topic, we come to grips and layout bluntly what Agile really is.

Watch, listen, learn, understand, and enjoy.

We are "Agile"!

Change Is Why We Do This!

As we noted in our overview initially, we are focussed on one word the tells us what agile is really all about. This one word, "change", is the thread that runs through the definitions that we look at in this topic.

This topic is intended to bring this one word into the Forefront of your mind as you begin to examine the world of agile.

Watch, listen, learn, understand, and enjoy.

We are Agile!

It's Time To Embrace Change!

We begin to use that one word, "change," more and more now. It is a subject, or might I say a word, that we have pushed away from in our traditional projects. This change always meant one thing. And that thing is going over the budget of time and dollars. And as you know, that is unacceptable. So instead of allowing change that will take us off-budget, we want to make sure we keep on budget, so we disallow change.

What we focus on in this short topic, is the importance of our organizations accepting this topic of change. And not just accepting change, but moving from just accepting change to embracing change. In other words, we want to change. We want our customers and stakeholders to ask for change, we want to create situations that create change. Why? Because we need to change to be successful.

Watch, listen, learn, understand, and enjoy.

We are Agile!

Agile Is Necessary!

The question of the hour. Is it necessary that we change what we are doing in the product development world?

It would seem that the governing bodies and the subject matter experts tell us that how we have structured ourselves in our organizations is not the way we need to structure our organizations going forward. These structures, or might we say management structures, are now failing us. We derived these organizational models from the changes made in our structures from the Industrial Revolution. However, we are no longer there, yet we still run our organizations as though we were.

These organizational structures do not allow for the volatility that we see today in our organizational world. Things continue to change and change quickly and change continually. Our organizational structures don't allow us to adapt to these changes the way we should.

What we are looking at in this topic is what our business world is discovering. And that is that it is necessary for us to adapt on a continual basis to change, and if we don't do this we will disappear as an organization.

The way that we have discovered that allows us to do what we need to do in product development to be successful, is what we call agile.

Watch, listen, learn, understand, and enjoy.

We are agile!

Are You Shooting At A Fixed Target?

In our last topic, we mentioned that today our organizations face a very volatile world. What we mean by that is that the world around us is rapidly changing on a day-by-day basis. In the midst of all of this, our organizations attempt to continually meet the needs of the people in this volatile world. To do so the products that we are building face what we call uncertainty as we begin to build the product.

This uncertainty creates an enormous amount of unknowns when we begin a project. What we then attempt to do at the beginning of our project is to predict where the organization will be when we deliver that product. We attempt to predict certainty in the midst of uncertainty. However, what we know for sure is that we cannot predict the future. So therefore we make assumptions, hoping the decisions we are making based on these assumptions will be valid when we deliver our product. However, we find that in the most cases these decisions based on assumptions are wrong.

In this topic, we address the fact that we have all this uncertainty which is accepted by all of those who are subject matter experts in this Arena of product development. The problem is how do we address this?

What we have attempted to do is to address it using a product developed approach that we have called waterfall. As we emphasized in this topic it has not worked for us and as far as we can see it will never work for us.

Why? Because it is a "Fixed Target." And, the target we are focusing on is not fixed, but is a "Moving Target!"

So what will work for us? The answer to that is agile.

Watch, listen, learn, I understand, and enjoy.

We are Agile!

How Are You Dealing With Uncertainty?

In this the final topic for this particular lesson we will be examining the philosophy of how we work in the middle of this world of uncertainty.

We will compare the traditional way that we have been working in the product development world using a linear waterfall approach to how it works in the agile world. We will follow through a scenario of creating a product but using this linear approach and arriving at our proposed destination minus the original Target. We will explain why this is the case. The scenario we use will be shown graphically so that you can have a good understanding of why this process has not been working. Or as the founder and originator of the waterfall methodology, Winston Royce, said in his paper written in 1978, 5 years after his original development of the model, this does not work, especially for large projects.

We will then view the same scenario of building this product using the agile philosophy. You will see in this model that as we build the product, why when we reach the end of the build we are exactly where we need to be. And the customer will receive just what they need to receive.

You should see by the end of this topic why any product development process really needs to follow the agile philosophy.

Watch, listen, learn, understand, and enjoy.

We are agile.

The Definition Of Agile

In this topic, we look at two definitions of agile. These two differences are quite simple but in their simplicity, they say a great amount. These two definitions come from two subject matter experts in the agile arena. One of these subject matter experts is part of the group that put together a document which we will be looking at shortly called the agile Manifesto.

We look at these two definitions and from both of them determine a specific thread that runs through them. This Thread is defined by a single word and it is this word that bears the essence of agile.

Therefore, think this through as you listen to what we say here. Gain an understanding of what we are saying here and saying in simplicity.

Watch, listen, learn, understand, and enjoy.

We are agile.

The "Two Professors"

In January 1986, the Harvard Business Review published a paper written by two Japanese professors. This paper contained information that began what we call the agile revolution. It began as a ripple and turned into a wave. This wave is today sweeping around the world.

The one core paragraph in this paper that made such a difference was this:

“The… ‘relay race’ approach to product development…may conflict with the goals of maximum speed and flexibility. Instead a holistic or ‘rugby’ approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.”

This caused product Developers to rethink the process of creating a product. From this paper came a number of Frameworks that would help industries like software development change the way they developed software.

This change has revolutionized the software development world.

Watch, listen, learn, understand, and enjoy.

We are agile!

Agile "Hits" The Information Technology World!

In 1993, jeff Sutherland, a former West Point cadet and Navy Fighter Pilot, a medical technologist, and coach of the turnaround of large organizations, joined forces with Ken Schwaber and put together an agile framework called Scrum.

In this topic we examine how this all started and then we journey through the 1990s into the early 2000s listing a number of the Frameworks that came into existence. This all came to a head in February 2001 at Snowbird Utah where a group of Information Technology subject matter experts came together and formed the Agile Alliance.

This group of Information Technology subject matter experts put together this organization and a document that laid the foundation moving ahead with the agile Revolution.

Watch, listen, learn, understand, enjoy.

We Are Agile!

What The Agile Manifesto Stands Upon

The agile manifesto begins with these words:

Manifesto for Agile Software Development

"We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work, we have come to value:"

As we indicate in the topic, this would seem like a motherhood statement that we use all the time and have used for many years. However, the last line of that quote is where the changes are.

This one statement is the foundation that we stand upon in Agile. We do not deviate from it, or relegate any of it to the Proverbial "back burner". It is important that we maintain its integrity, as it maintains ours as Software Developers.

Take the time to listen to this short video before you move to the next topic which looks at the values that are laid out in the manifesto.

Watch, listen, learn, understand, and enjoy.

We are at agile.

The 4 Values Of The Agile Manifesto

In this topic, we discuss the four values as documented in the agile Manifesto. These are the four value statements that were discussed and agreed upon during that time.

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiation

4. Responding to change over following a plan

What we say when we look at these values is that there are two sides, a left side, and a right side. Each of these sides contain value. In the past, we have typically put greater value on the right side of the statements. In the agile world, we say that the left side has greater value than the right side.

Both sides have value, but our focus is on what is on the left side. If I work with an organization that is having difficulties in transitioning to the agile philosophy from the top of the organization to the bottom, this is where I go. I review with the senior executive and the managers, and each of the teams, the value statements, and typically I find that the greater value is still on the right side of these statements. This results in challenges and most times failure.

Take time to listen as I talk through this and give examples of why it is so important that we keep these values in front of our minds as we work with organizations to transition and establish them in this great philosophy. It is something that must be remembered by everyone working in the agile space.

Listen, watch, learn, understand, and enjoy.

We are agile.

Agile Principle 1

We follow these principles:

"Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software."

It is interesting that most agile practitioners think this is all about the final delivery of software to the customer. It is, and it is not!

Let me explain what I mean by that.

As Jeff Sutherland so often quotes, "Scrum is all about the feedback cycle/loop". You see, the reason that we want to deliver working software quickly to our stakeholders is so that we can get their feedback. It is the feedback loop that keeps our project on the correct course.

Please listen to what we say in this video as we lay this out in detail and indicate what our mantra is and should always be.

Watch, listen, learn, I understand, and enjoy.

We are agile!

Principle 2

We follow these principles:

"Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage."

This has been one of the biggest hurdles that we have faced in the software development industry since the beginning of a waterfall process. What I mean here is that once we have begun a software development project, we resist changes to our original design because it has a negative impact on our budgets. Therefore, the changes that are needed for the product that we are building to meet the real needs of the stakeholders, are left for a further release.

This was actually predicted by the founder of the waterfall process, Winston Royce, back in a report he wrote in 1978, 5 years after he instigated the waterfall process. He wrote that the waterfall process would not work, especially for large projects, because of, and here it comes straight from the founder of the waterfall process, "rigid based requirements"!

In the agile world, we take the opposite philosophy. We welcome changing requirements all the way through the development cycles of our product.

Let's talk that through, in this topic. We teach why we do it, and how we do it.

Watch, listen, learn, understand, and enjoy.

Agile Principle 3

We follow these principles:

"Deliver working software frequently, from
1 week to 4 weeks, with a
preference to the shorter timescale."

In this topic, we study the importance of delivering software, in short, create or build cycles. When we look at FrameWorks like Scrum we see that the focus is on the feedback loop. The intent here is to make the feedback loop as short as possible. This is because the longer the cycle we work on to get the feedback from the stakeholders if the feedback indicates much change, the more change we have to make. And longer the project.

Our core focus is to keep this cycle of building as short as possible. This allows us to get the feedback sooner and allows us to learn faster, and fix faster.

Watch, listen, learn, understand, and enjoy.

We are agile!

Agile Principle 4

We follow these principles:

"Business people and developers must work
together daily throughout the project."

In this topic, we discuss the agile Manifesto principle number four. The importance of what is stated in this topic is that on a daily basis the team, consisting of both business and builders, must work together.

What is important to understand here is that we don't do things because the framework tells us to do them, we do things because they adhere to the principles of agile. For example, we don't conduct daily stand-ups because scrum tells us to, we conduct stand-ups because they allow us to adhere to the principal number four as laid out by the agile Manifesto.

With that in mind, listen, watch, learn, understand, and enjoy.

We are agile.

Agile Principle 5

We follow these principles:

"Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done."

In this topic, we begin to deal with the people side of agile. One of the things that we state a number of times in all of our courses is that the foundation of agile is the team. And that team consists of people.

It is the people that we focus on in this particular agile principle. In the agile world when we look at teams we have specific criteria that we include. We list the criteria this way:

• Small teams

• Collaborative teams

• Cross-functional teams

• Self-organizing teams

• Autonomous teams

With these specific criteria, we understand that not all individuals want to fit into a team like this. We look for specific individuals and then we supply them the environment to succeed in. That is what this particular topic is about.

Watch, listen, learn, understand, and enjoy.

We are agile!

Agile Principle 6

We follow these principles:

"The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation."

Topic number 6. The best Communication is face-to-face communication. This is an interesting subject since we have lost sight of much communication being done face with the emailing and texting facilities that we have today. So much of our communication is done through social media. Much of this does not consist of communication actually done face-to-face.

With that said we still have technology that does allow for much in the way of face-to-face conversation done remotely. It is ideal if we can have a collocated team in one room, much of our organizations today we end up with geographically distributed teams.

This does not mean that we do away with face-to-face communication. As a matter of fact, we still do just as much face-to-face conversation, but we do it through technology. In this topic, we discuss the psychology and the need for such a conversation.

Watch, listen, learn, understand, and enjoy.

We are Agile!

Agile Manifesto Principle 7

Principle 7: "Working software is the primary measure of progress."

It is interesting to note that with the traditional software development methodologies, we typically measure our progress but the amount of documentation that we deliver. Many of our methodologies call these pieces of documentation, deliverables.

For example, if we complete our business requirements document which may consist of two thousand pages, on the date that we had predicted, we say that we are on time. However, let us know here that we really only have one deliverable in software development. And that deliverable is our application or our software. Yet at this point, we have not even started on that one major deliverable. So the question is how do we say we are on time?

In the agile world, we measure our progress by how much software we have developed and how much of this software has been user acceptance testing. That is the litmus test of our key deliverable.

Please watch, listen, learn, understand, and enjoy.

We are agile!

The Agile Manifesto Principle 8

Principle 8: "Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely."

In this topic, we discuss how in the agile World our Focus is on maintaining a fixed pace from a work perspective.

What we mean by this is that we pick a specific iteration length, which is what we name our time box, and we maintain this specific length for the entire project. We typically start on the same day and end on the same day for the entire project.

This creates a Cadence or rhythm that has a very large psychological impact on how we work. We discuss this in the topic here and we understand that this Cadence is necessary for us to be successful in the agile world. We discuss the underlying psychological impacts that we have discovered here and much of that comes from the studies in the arena of Neuroscience.

Please watch, listen, learn, understand, and enjoy.

We are agile!

Agile Principle 9

Agile Principle 9: "Continuous attention to technical excellence
and good design enhances agility."

One of the issues that we have faced in our traditional software processes is that we have accumulated what we call a large amount of technical debt. This technical debt develops from not going back and refining what we have built because we have not allowed a budget for it.

The more complex and more extensive our systems become due to organizations diversifying and distributing themselves on a global basis, the harder it is for us to go back and fix problems. Our typical response is we will fix it in the next release.

In the agile world, we continue to refine and refactor our code, our designs, and our product on a continual basis. Much of that comes from our short and continual feedback loops.

Watch and listen as we talk through this process and what it means for the Excellence of our products.

Enjoy.

We are agile!

Agile Manifesto Principle 10

Principle 10: "Simplicity--the art of maximizing the amount
of work not done--is essential."

In this topic, we are going to discuss a subject that I want you to pay very close attention to. The reason is that most people don't quite understand what we mean when we talk about our focus being "the ability to maximize the amount of work we don't do".

Most information Technology practitioners believe that our focus should be on maximizing the amount of work that we do. The problem with this traditional approach is we begin to work on things that are no longer valid due to the changes that have happened around the world and around our businesses.

Our traditional approach has been this concept of "big design up front" or what we call BDUF. When we take this approach we plan our product based on where the business is at that time. Yes, we do try to project and predict where the world will go but we can't do that. That is just a fact of life.

In the agile world, we keep on adapting our product and eliminating those things that we no longer need because the world around our business has changed.

Watch and listen as we discuss this in greater detail. And remember ……

We are agile!

Agile Manifesto Principle 11

We follow these principles:

"The best architectures, requirements, and designs
emerge from self-organizing teams."

In this topic, we will begin addressing the concept of self-organizing teams. This is actually one of the areas that we have seen a lot of apprehension at the Senior Management levels. Why? Because accepting this way of operating is very different from what they are used to.

Understandably so, since this is a very different model of organizational structure than what we have traditionally been trained in. Especially those in the Senior Management ranks who have spent years operating under the old model. That model is one of command and control.

In the agile world, we learn to trust our teams who are subject matter experts. On a day by day journey through our project, they self-organize based on the changes in the environment around them. Those changes come from business changes, people changes, government changes, and overall World changes.

Success comes when teams are able to adapt on a day-to-day basis to what is happening in the world around them. This is what we will discuss in this topic.

So we say, listen, watch, learn, understand, and enjoy.

We are agile!

Agile Manifesto Principle 12

We follow these principles:

"At regular intervals, the team reflects on how
to become more effective then tunes and adjusts
its behavior accordingly."

In this topic, we look at the 12th and final principle behind the values in the Agile Manifesto.

In this principle, our Focus is on improving our process. Let us state something emphatically at this point, and that is this. One of the driving Passions for any team in the agile world is continuous Improvement. We not only focus on the continuous improvement of the product we are working on through the ongoing short feedback loop, but we also focus on the continuous improvement of how we're building that product.

That is what this topic is focussed on. The team joins together at the end of every iteration of development and reviews the things that could be improved in the process as they work on delivering the product. The team then comes to an agreement on action items that they will take in the next iteration to make these improvements. This continues throughout the entire project.

With that stated, let's discuss this in detail in the attached video.

Watch, listen, learn, understand, and enjoy.

We are agile!

Agile Planning and Software Engineering Frameworks

In our traditional software development world, we typically build our products using what we call a methodology. These methodologies are prescriptive as we have mentioned a number of times already. By this, we mean that the intent is for all individuals to follow the same process, or we might say the same prescription. If we all follow the same process as we did last time we then should achieve success.

In the agile world, we know that this is not the case. Every project is different. Every set of stakeholders is different. Every customer is different. Every combination of team members is different. Therefore, what we did last time that worked in most cases will not work this time. Why? Because the environment is different.

What we do in the agile world is we use Frameworks. These Frameworks provide us a pattern or we might say boundaries that we work within. However, within the pattern or boundary, we adapt to the environment that we are working in. To the stakeholders. To the business. To our economic situations. And so forth.

What we will look at in this topic is the set of Frameworks that we use in planning and in software engineering.

With that said, listen, watch, learn, understand, and enjoy.

We are agile!

Agile Project Management Frameworks

We are currently discussing agile Frameworks. In our last topic, we looked at those Frameworks that address what we call the software engineering aspect of product development.

In this particular topic, we will discuss what we call the management Frameworks used in agile product development. There are two of these particular frameworks that are specifically used in our industry. And we look at both of these from a high-level perspective. The number one framework is called Scrum. The number 2 framework is called Kanban.

We briefly look at each of these Frameworks here and understand that we borrow techniques from the other Frameworks, such as the software engineering Frameworks. We manage them through these particular agile management Frameworks.

In future courses, we will devote entire classes just to discuss each of these Frameworks.

With that said, watch, listen, learn, understand, and enjoy.

We are agile!

Yes, Waterfall Still Works!

In this lesson, we are going to begin examining where the agile philosophy works best in product development. Now when I take this tact as I put together my lesson, I always like to take the perspective of looking at the reciprocal first. In this case, the reciprocal of where agile works best is where waterfall works best.

Therefore, in this topic that is exactly what we will examine. Where might we use the waterfall approach from a development perspective? What kind of products would this work best for?

Then in the next topic, we will examine where agile will work best.

Watch, listen, learn, understand, and enjoy.

We are agile!

Agile Really Works Well Here ........

Let's talk now about where agile works best. There are specific criteria that we look at when we review a product and create a project to build that product, that allows us to understand it works well using the agile philosophy.

In this topic, we will examine the particular set of criteria that we look at. This tells us very quickly whether or not we should actually build it using the agile philosophy.

Please take the time to think this through, especially if you are a decision-maker in the arena of software development. Watch and listen to this video more than once to make sure that you gain an understanding of what you need to make decisions based on.

Please listen, watch, learn, understand, and enjoy.

We are agile!

The Problem Solving Process

Waterfall as we know it in the product creation world was created to help manage the flow of developing aa product. It was a way of moving from phase to phase of the problem-solving process, completing the phase in its entirety, before moving on to the next phase. This created numerous problems because each phase had to be complete and signed off, even years before the product was actually delivered.

It is interesting to note that in a paper that Winston Royce, the creator of the Waterfall process wrote in the later 1970s, he emphasized that this process does not work, especially for large projects.

We will once again wrap up our understanding of the process that Winston Royce put together so that we can understand how we still use the phases of development but in an agile way.

So sit back and listen, watch, learn, understand, and enjoy.

We are agile!

How We Do It In The Agile World?

Now that we have once again reviewed the waterfall process and how we actually work through it, we will show you now how the problem-solving process works in an agile framework.

Instead of doing things in a linear way, we now work in a parallel way. That might be difficult to mentally grasp at the moment, but listen and watch as we explain it in this video.

I emphasize here that in the waterfall process, we have a phase for example called analysis. That phase must be started and then completed its entirety before we can move on to the next phase called design. So we see a specific begin-point and endpoint to analysis.

We then follow the same process for design. We Begin the design and then wait for its entire completion before we then sign it off and move on to the following phase. This continues for the whole project.

In the agile World, analysis begins at the beginning of the project and ends at the end of the project. The design phase begins at the beginning of the project and ends at the end of the project. The construction phase begins at the beginning of the project and ends at the end of the project. The testing phase begins at the beginning of the project and ends at the end of the project.

So what we see here is that we are continually analyzing, designing, building, and testing from the beginning to the end. A very different way of developing a product.

Therefore, with that introduction, listen and watch this video to understand what we are saying.

Watch, listen, learn, understand, and enjoy.

We are agile!

Course Wrap-Up

In this topic, we quickly wrap up the course and make some recommendations as to what you should do next. This is a very important step that you need to take if you want to excel in this amazing world of "agility" in product development.

You now have an understanding of agile, but now you need to know how to put it all together. And this is what our Frameworks are for. The next course which is really important for you to know and understand is all about the most popular framework in the world today called "Scrum."

In our next course we do a deep into this framework, and take you by the hand leading you from a novice category to an expert in working with scrum.

Watch this video and enjoy it.

We are agile!

The Summary

Finally, here it is all put together in one short 12-minute video. This is what we have learned in this course. You have access to this video on a continual basis.

I have done this so you can go back and review it, and review it, and when you forget things, you can go back and review this short video again.

It has been great having you on this course, and we certainly would consider it a pleasure to have you join us in some of our other courses.

Our dream is that you become agile!

You are agile!