Category Archives: Theory of Agile

How-To Apply Agile, product owner, Theory of Agile

Choosing the right approach for project delivery

Leave a comment

Let’s begin by agreeing that the quest for success starts with the right approach to support project delivery.

As a practitioner in the project, program & portfolio management space for many years now, I have seen different delivery approaches work for different organizations based on project characteristics and organizational needs. Each project need will have a spot on the continuum, from the predictive waterfall approach to an Agile approach.

Meanwhile most of the practitioners I interact with seem to have chosen a side – there are some strong believers of waterfall that stresses meticulous planning and a sequential delivery approach, while others are strong believers of less process heavy, iterative delivery approaches.

I, personally, beg to differ. I believe that both of these approaches have their own strengths and weakness and there can be successful co-existence between these methodologies. Being mostly surrounded by waterfall experts, I have seen a huge gap between traditional project management perspectives and the newer, more Agile approaches.

Most of these gaps stem from limited knowledge on the subject from the opposite side. Specifically, here are some key disconnects that I have encountered over the years

An Agile approach is the extreme opposite of Waterfall approach

Not true.

Even in the most Agile centric environment, many of the Waterfall project management principles are valid even if applied in a different context. These principles might not fall neatly into some of the typical knowledge areas of traditional approaches, such as scope, time and cost management – but there is still a need for striking the right balance between planning, control and agility. All project life cycles include a planning element. What differentiates the life cycle is how much planning is done and when.

For instance, risk management processes, in traditional waterfall project management, are implemented to control & monitor risks. An Agile approach, on the other hand, implements risk management in a broader sense by coaching team members to incorporate risk management principles into the way the work – thereby eliminating some of the risk monitoring aspects found in the waterfall approach. Both approaches have risk management aspects – it is just implemented differently.

Being Agile only impacts the IT departments

Again, not true.

Any methodology (Agile or Waterfall) requires organizational commitment which extends far beyond the IT or Project Management teams. Not to forget, it may require some major shifts in organizational culture to make it work. What makes any delivery approach successful for an organization is the commitment by the organization to make it successful.

It starts with deciding which methodology will be right for the organization; which one will support their current and future goals and which one can bring them closer to meeting their bottom line. It can very well be a hybrid between traditional and contemporary delivery approaches. What needs to follow is the commitment throughout the organization to change their old mindsets, processes & come onboard to support the change.

The point that I am trying to make here is that thinking of any delivery approach as being a silo to a particular department or team is incorrect. It is far broader than that.

You need to make a choice – Agile or Waterfall

Do we really have to? The idea that you either need to follow a methodology by the book – or not at all. is preposterous. The fact is, an organization can choose to design a delivery approach that creates a perfect marriage between plan driven approach and agility which aligns with the organization’s strategy.

Of course, certain changes would call for a traditional waterfall approach, for instance building a house, and some would call out for an Agile approach, for instance building an app to control the temperature of the house. The fact of the matter is that it doesn’t need to be as rigid as some practitioners perceive it to be. The right thing to do is to be focused on delivering a solution in the most efficient way possible rather than being solely hung up a particular methodology and its boundaries.

In conclusion, practitioners from both communities (traditional & Agile) are so focused on promoting the benefits of their own delivery stream that they tend to overlook the idea of co-existence. It doesn’t have to be a black-and-white proposition – it can very well be a mix of the two – you just need to strike the right balance.

I am a strong believer that there is no one right solution for everything and that a peaceful co-existence can exist amongst different perspectives.  I also believe that better solutions are yet to come, ones that are not constrained by current boundaries and that are focused on better supporting the diverse and ever-changing demands of the world we live in.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Theory of Agile

Agility: Knowledge Generation and Beauty

1 Comment

Compromised Agility

The authors of the Manifesto for Agile Software Development expound a set of values and principles that define “Agile Software Development”. These values and principles, written in 2001, became the focal point of a revolution in how software developers work.

In the last several years, that revolution has spread beyond software development to encompass other aspects of technology, and beyond technology into operations, management, engineering, business development, sales, marketing and even outside of for-profit organizations into education, health, government, community and charitable organizations. Originally written in the context of software, we can easily generalize the values and principles to other types of work. For example, the Manifesto refers to valuing “working software over comprehensive documentation.” We can easily generalize this to a more abstract statement that we value “results over bureaucracy.” The other values and principles can be similarly abstracted.

As the revolution has spread, unfortunately, the values and principles have also become compromised or selectively applied. Perhaps most obvious is how Agile Lifecycle Management tools such as Jira have often been substituted in place of the first value of the Manifesto: “we have come to value individuals and interactions over processes and tools” [emphasis added]. The irony of this substitution seems to be lost on those selling and buying these tools. Many other compromises or selective applications are common, and they are usually unique to each organization’s circumstances.

This evolution of the application of the Manifesto’s values and principles can be understood negatively or positively. I’m an optimist; yet we need to look at the negative, critical side before we can see the positive.

Cargo Cult Agility / No True Agilist

There are two common ways to understand the failure of organizations to do “true Agile”. Both are negative in the sense that they are criticisms without a reasonable solution to help an organization out of the situation into a better situation. As a consultant seeing many organizations, as a trainer hearing about many organizations, and as an active member of the global community of Agilists, I hear these criticisms quite regularly.

The first approach to understanding this partial agility is by comparison to the cargo cult mentality:

A cargo cult is a millenarian movement first described in Melanesia which encompasses a range of practices and occurs in the wake of contact with more technologically advanced societies. The name derives from the belief which began among Melanesians in the late 19th and early 20th century that various ritualistic acts such as the building of an airplane runway will result in the appearance of material wealth, particularly highly desirable Western goods (i.e., “cargo”), via Western airplanes.

In this approach to understanding an organization’s failure to embrace true Agile, the critic asserts that the leaders and employees of the organization do not really understand true Agile and are only practicing the obvious ritualistic aspects such as daily stand-ups (from Scrum), note cards on a wall (from Kanban), or user stories (from Extreme Programming). This criticism has some merit: many people are told to “do Agile” without proper training and coaching to understand the theory or the contextual applicability of various practices. The critic continues to compare this approach to Agile as a belief in magic: that the benefits of Agile can be gained through an application of the rituals without an understanding of, and more importantly adoption of the values and principles.

The “cargo cult” criticism does not offer a solution. When asked, the critics themselves will say, effectively, “well, you just need to really understand it!” This criticism also suffers from the inherent notion of the superior position of the critic: “I understand it… you don’t.” Not particularly helpful, especially for the staff in an organization who depend on executives and other leaders to support true Agile. And, not particularly helpful for the executives who often do not have the skill to support such a deep change.

The second common approach to understanding the failure of organizations to achieve real agility is the “No True Scotsman” comparison. This is a bit more challenging to describe because it is actually a criticism of other critics. Wikipedia describes No True Scotsman this way:

No true Scotsman or appeal to purity is an informal fallacy in which one attempts to protect a universal generalization from counterexamples by changing the definition in an ad hoc fashion to exclude the counterexample. Rather than denying the counterexample or rejecting the original claim, this fallacy modifies the subject of the assertion to exclude the specific case or others like it by rhetoric, without reference to any specific objective rule (“no true Scotsman would do such a thing”; i.e., those who perform that action are not part of our group and thus criticism of that action is not criticism of the group).

The starting point of this criticism is actually the reciprocal of the cargo cult criticism: the critic conflates true agility with the compromise happening at an organization and then accuses agility of being a failure. This criticism is often brought up in the following style of discussion:

Person A: Agile sucks because Big Corp is trying Scrum but it is really just an excuse for executives to micro-manage every little bit of work.

Person B: But Scrum and Agile are against micro-management! Big Corp isn’t really doing true Agile.[NOTE: this is the cargo cult criticism in brief.]

Person A: That’s just an excuse. You’re using the no true Scotsman argument and it’s a logical fallacy. Agile is what people are actually doing, therefore Agile sucks.

Person B: !

Interestingly, this argument style is often used between competing brands of agility. Leaders of both the Scrum and Kanban approaches to agility are well known for this approach to argument, particularly about each other’s chosen approach: “method X doesn’t work, as clearly seen by all the organizations doing X badly, therefore you should try my method Y which does work.” Again, this is ironic given the first value of the Manifesto for Agile Software Development “…over processes….”

Like the cargo cult criticism, the no true Agilist criticism does not offer a solution, other than reverting to a non-Agile approach to work (or more rarely, another approach that suffers the same imperfect implementation in organizations). And, like the cargo cult criticism, there is some truth in the no true Agilist view: legitimately, many organizations are doing a very very poor job of applying the values and principles (and associated practices). The conclusion that Agile sucks and therefore we shouldn’t even be trying is forgivable. However, the people online proclaiming this problem tend to be loud in their conclusion: let’s go back to our halcyon bygone days where the wind was fresh, the sun was bright, and we were all bucolically happy with our defined roles, our rigid processes, and our tools we could blame for every failure of our efforts (ironic hyperbole intended).

Both criticisms, reciprocal as they are, leave a gap. They don’t offer a full explanation of what is happening, nor do they offer a positive path to improvement. For that, we need to change our perspective just a bit.

Knowledge Generation and the Benefit of Time

I have been working with Agile methods for over 20 years. As a programmer and then enterprise architect, I adopted agile methods relatively early – even before the term “Agile” was applied to software development and these methods were referred to as “lightweight” methods. I mention this not to tout my expertise or even my experience, but rather my perspective. I’ve “been around” enough to know with a fair degree of certainty the following important points:

  1. There is no large organization that has successfully “transformed” from a non-Agile state to an enterprise-wide Agile state. By “large”, I mean at least 5000 total employees.  By “transformed” I mean that it grew up using traditional techniques and has fully switched over to Agile management techniques throughout the total employee population. And by “successfully” I mean that it has sustained the use of Agile management techniques at the organizational level through at least one boom/bust economic cycle, and one change of C-Level leadership. (If you are reading this, and you know of such an organization, I would be excited to hear about it!)
  2. Large organizations that have high levels of agility typically started as small organizations with high levels of agility. Google, Amazon and Facebook come to mind. Their level of agility includes a high level of technical agility in addition to their management agility. I’m not sure, but I suspect that these two types of agility go hand-in-hand; certainly the Manifesto for Agile Software Development suggests they do go together.
  3. The only proof of transformation is in the sustainability of that transformation through existential crisis.
  4. Partial or compromised agility is the only kind of agility that is, so far, successfully sustained in a few rare cases of large organizations. Capital One is an example of this. They have been trying to adopt Agile methods and approaches since 2001. They have tried many techniques, and had many ups and downs in their journey. In 2017 at the Lean Kanban North America conference, two senior Agile coaches from Capital One asserted that they still have a long way to go for full enterprise agility – after working at it for 17 years already.

How does this compare to other management philosophies? The history of the Toyota Production System and Lean manufacturing, at least 50 years in the making so far, has shown us that revolutionary changes in the way work is done, can take many decades to become normalized. In the 1980’s and 90’s many organizations adopted “lean” as a management fad.  We saw a swift rise and then fall in the popularity of lean. But the core principles and ideas of lean survived, and have continued to spread throughout many industries. Now, many organizations are “culturally” lean: they won’t revert to other methods of working even in crisis situations… and many others are not yet there.

With a timeline of 50+ years, perhaps we can consider our efforts to transform organizations to a greater level of agility in a more positive light.  Human society at large is learning about agility though many many experiments run in thousands of organizations. Sometimes these experiments are motivated by wise and considered thought, but often, they are motivated by the faddish popularity of Agile methods such as Scrum, SAFe, and Kanban. Regardless of the motivation, the compromises organizations are making as they attempt greater levels of agility are part of a larger process encompassing all of human society in which knowledge generation is the primary outcome.

There is still one more problem to address: that individuals and organizations continue to try to improve agility even when they have experienced it done badly or seen it fail to take hold. One of my favourite authors and a prominent figure in the Agile community is Ron Jeffries. In the last couple of years, he has started to call out “Dark Scrum” as a blight in organizations that is causing suffering. I believe there is also “dark kanban”, “dark SAFe”, “dark extreme programming”, etc. These dark implementations of the various paths to agility, aren’t actually paths to agility for the people, teams and organizations implementing them. So again, why do people keep coming back to these methods?

Motivation to Try Again and Beauty

Let’s return to the Manifesto for Agile Software Development and here quote the four values. If you have read them before, even many times, I encourage you to read them again, slowly, and savour them:

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

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

I would like to assert that anyone who has read these values, and further, read the principles behind the manifesto has been attracted to the inherent beauty of these ideas. This beauty is the source of the motivation to try again. This beauty is the source of the influence of the manifesto. This beauty is the reason why so many want to “own” it through the creation of their own brands, methods, schemes, and promotions. And, this beauty, while it is constantly struggling against corrupting influences, is powerful enough to inspire people to come back to it even when they have seen the dark side of agility.

Real agility is a culture founded on the beauty that inspires these principles. It’s not any particular method, it’s not a formula, it’s not merely a set of laudable or effective practices. Rather, this beauty is inspired by the Spirit of the Age in which we live. As individuals, teams and organizations, we will rarely live up to that beauty, rather we will experience it in moments, greater or lesser, strung together by our efforts to increase humanity’s collective knowledge. And as that knowledge grows, our patience for the partial, incomplete agility of many organizations will also grow for it is the source of our new-found knowledge.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, Theory of Agile

Unpacking the Fifth Principle of the Agile Manifesto

3 Comments

The Agile Manifesto was signed and made public in 2001. It begins with short, pithy statements regarding what should be the priorities of software developers, followed by Twelve Principles. In this article I want to call attention to the fifth principle in the Agile Manifesto, which is:

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

https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/

Although it appears to be a very simple statement, I suggest that it is jam-packed with profitable guidance, and is essential to, and at the heart of, real Agility. Human qualities must be considered.

Motivation

The first part of the principle urges us to build projects around motivated individuals.  What does this imply?

The idea of “building a project” makes it a process, not necessarily a fait accompli. It can change and be altered as one works toward it. There may be a structural roadmap, but many details and aspects can change in the “building.”

The second part of the statement describes motivated individuals. The verb “motivate” is an action word, meaning to actuate, propel, move or incite. Thus, in this line, is the “project” the thing which will “move or incite” those being asked to carry it out?

Or do we understand this to imply that the individuals are already “motivated” in themselves, which is an emotional condition of individuals? Is this motivation already there prior to starting a project?

The topic of motivation is rich. How does motivation occur? Is it the culture and environment of the company, lived and exemplified by it’s leaders, which motivates? Or is motivation an intrinsic quality of the individual? It may be both. (Daniel Pink, author of “Drive,” uses science to demonstrate that the best motivators are autonomy, mastery and purposeful-ness – ideas which are inherent in the Agile Manifesto.)

In any case, the line itself suggests that the project may be a) interesting to pertinent (perhaps already motivated) individuals, b) do-able by those same individuals, and c) contains enough challenges to test the mastery and creativity of the individuals. In other words, it’s going to be a project that the individuals in your company care about for more than one reason.

Environment

The second line from the fifth Principle has two distinct parts to it. The first part, “Give them the environment and support they need” puts a great deal of responsibility on whoever is assigning the project. Let’s look at the idea of environment first.

In a simple way, we can understand environment as the physical place which influences a person or a group. It can be any space or room; it can refer to the lighting, the colours, the furniture, the vegetation, the walls, whether water or coffee is available – physical elements which will certainly affect the actions of people and teams. For example, creating face-to-face collaboration environments is also part of the Agile Manifesto.

But we must remember that environment also entails the non-physical ie, the intellectual, emotional, or even the spiritual. Is the environment friendly or not? Cheerful or not? Encouraging or not? Affirming or not? We can think of many non-physical attributes that make up an environment.

Support

These attributes allude to the second part of what’s to be given by an owner or manager: “…and support they need.” This idea of support pertains not just to helping someone out with tools and responding to needs, but that the environment is supportive in every way – physically, intellectually, emotionally and spiritually. This may be a more holistic way of considering this Agile principle.

The last part of the statement is of great importance as well: and trust them to get the job done.

If you as product owner, or manager have created motivation, environment and support, then the last crucial requirement of trust becomes easier to fulfill. There is nothing more off-putting than being micromanaged, supervised or controlled with excessive attention to small details. Trust means you have confidence in the capacity of your team and its individual members. It also implies that they will communicate with transparency and honesty with you, and you with them, about the project.

Context

The principles of Agile do not exist in a vacuum, because, of course, other principles such as the following, are relevant to this discussion:

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

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

This fifth principle has application far beyond IT projects. I wanted to reflect on it because it speaks to human qualities, which must be recognized as a key factor in happy work places, and in any high-performance team.

Valerie Senyk is a Customer Service agent and Agile Team Developer with BERTEIG.

For more information please go to http://www.worldmindware.com/AgileTeamDevelopmentWorkshopStage1

Also read about BERTEIG’s RealAgility Program: http://www.berteig.com/real-agility-enterprise-agility/

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
How-To Apply Agile, Professional Development, Scrum Master, scrum team improvement, Theory of Agile

Practicing Scrum (subversively): you CAN do it!

Leave a comment
photo by V. Senyk
photo by V. Senyk

by Jerry Doucett and Valerie Senyk

You want to be practicing Scrum! You’ve taken Scrum training, received your industry certification, and perhaps even experienced being a Scrum team member. In your heart you believe Scrum is the right tool and approach for you, and you believe your current organization and your customers could really benefit from Scrum practices. 

However, for whatever reason your organization is either hesitant to consider Scrum or believes it’s a bad idea. Perhaps there was an experience with a poorly executed pilot. Perhaps your leadership see it as being too risky.

What do you do?

This article explores how you could subversively practice ScrumMaster-ing in your workplace without getting into trouble or breaking the rules. (Ssh…we won’t tell!)

Before you even begin strategizing, you need to ensure that what you do aligns with the Scrum values, namely:

 

Doing Scrum subversively will certainly take considerable courage, focus and commitment on your part. Be aware you will be challenged to respect the existing organizational culture and norms, and your organization may push back on your efforts.

You also need to acknowledge that the very act of being subversive means you are not being completely open or transparent that you are trying to practice Scrum.

Or you could tell your workmates, “I’ve had this terrific training in Scrum and could we try a few of the techniques to see how they work?” Then introduce something as simple as time-boxing or holding retrospectives with your colleagues.

You will also want to ensure what you do is harmonious with Scrum Theory and the pillars of empirical process, which are:

1. Transparency 2. Inspection 3. Adaptation

Normally, one could say there’s a direct conflict between being transparent and being subversive. Keeping this in mind, it is imperative you be absolutely transparent on the actions you are taking and what the specific goals, outcomes or learnings are that you hope to achieve.

However, given the circumstances you’ll likely choose to not use Scrum terminology to describe what you are doing. In other words, describe the practices and activities that you are implementing or recommending, express their benefits and what you hope to accomplish, but don’t explicitly call them by their Scrum name.

As for Inspection and Adaptation, those approaches should be perfectly aligned with your intent to try to help your company become a learning organization. That means you will need to park your ego at the door and accept the results. If your learning shows your subversive Scrum activities do not provide the benefit you’re aiming for, you will need to stop them regardless of whether you think they should work.

Let’s explore some activities and practices you may want to tactfully consider to help your organization benefit from Scrum (without actually “doing” Scrum).

1. Lead by Example

As someone that appreciates the values of Scrum, you should aim to educate others and provide them with a similar understanding. That means practicing these values in how you show up and in everything you do, even explicitly calling out certain actions when they are a prime example (whenever it is appropriate).

This does not mean preaching! Instead, it could be sharing your thoughts about something when contributing to a decision, or simply pointing out when and how something that aligns with the values contributes to a better team, a better experience, or a better solution.

Leading by example also means being human and honest when mistakes are made or when failures occur. This can be particularly risky in an organization that has not embraced Agility, or where failure is frowned upon. That is where you need courage, and a commitment on your part to hold improvement of the work above your own individual career needs.

2. Communicate More

Make a concerted, conscious effort to communicate with your team and partners more. For example, get up out of your seat and spend more time in informal face-to-face discussions rather than sending e-mails or chat messages.

Perhaps you can have short, informal meetings with just the team either daily or several times a week to see what’s been done, what needs to be done, and what challenges the team is facing. The key here is to keep it short, focus on what is needed to move work forward, and define actions to address issues. Then always follow up and make sure the actions are being pursued and that progress is shared with the team.

3. Be Open And Transparent

Although you may consciously choose to not use the proper terminology and language of Scrum, the key is to always be honest about what it is you are trying to do, why it’s important, and what the desired outcomes are.

To this end the goal should be to become an organization that “learns about learning”, constantly tries to improve, delivers value faster, and applies new knowledge in the best possible way. Scrum may be a fantastic catalyst for that, but there are many other approaches that will achieve similar results.

4. Use Better Meeting Practices

Another approach to consider is improve meeting experiences by time-boxing and defining a specific scope for each meeting. Setting a time limit and outcomes for a discussion helps create a sense of urgency, manage expectations and focus the conversation on the most important topics. The facilitator will need to enforce these constraints, otherwise you lose the effectiveness of the practice.

5. Have One or More Key Stakeholders Empowered to Make Product Decisions

This may be a considerable challenge in organizations where there is little appetite or understanding about Scrum practices, but do what you can given your authority and influence. If possible, try to have a single voice (key stakeholder) defined as the person with the final authority on the product or service that your team is delivering. Work with that individual to set them up for success by connecting them with the other stakeholders, perhaps facilitating discussions with them, and showing the key person(s) effective techniques for prioritizing the work that is being asked for.

6. Limit Efforts to What Matters Most

One practice that is important to apply, but often difficult to master, is focus. Limit work and discussions to the most important tasks and activities, and request that other discussions on lesser-important work be delayed. Always try to focus the conversation back to what is currently the most important work.

On occasion you may even want to point out times when plans were well-defined in advance but ultimately changed a lot when the actual work was in progress. This indicates the waste in planning too much up front and in constant task-switching. When done in conjunction with time-boxing this practice becomes a little easier.

On a macro scale, try to limit development to smaller chunks of end-to-end deliverables. In other words, deliver small things often all the way to completion as much as possible (e.g. to a staging environment). Then show the outcome and deliverable to stakeholders and customers, explaining that although the final product may not be done, this is to get them something fast and gather feedback.

7. Reflect on Learning

When possible, ensure that reviews of completed work happen frequently. Ensure the outcomes, functionality and value is shown and that learning (for the product as well as the methods) are part of the discussion.

Without becoming intrusive, seek stakeholder feedback frequently and informally. Be willing to demonstrate an ability to pivot plans based on that feedback.

As a team, hold informal retrospectives of how you worked together. If the term “retrospective” is contentious, consider calling them something else, such as a debriefing.

8. Visualize and Display Work

Have your own personal backlog and list of current activities visible at your desk. Use post-its to represent all work that you have on your plate, and ensure it is always up-to-date. Prioritize the work items you have coming up, and visually represent this as a rank-ordered list of things that you have to do.

It won’t take long for people around you to notice what you are doing and ask about it. Use this as a great opportunity to educate others on the values of transparency and focus.

9. Keep Your Team Size Appropriate

If you are on a particularly large team, see if it is possible to split that large team in to smaller groups. The benefit is more face-to-face time and interaction across the new team, an increased sense of belonging and commitment to the new team’s purpose, and it should also be easier (in theory anyway) to get decisions made and increase alignment.

The challenge will be finding a logical way to split the teams to mitigate dependencies of people, skills and products, and ensuring the new teams can still collaborate with one another. Geography might be a good way to split the team if you are distributed, but you would need to ensure all the skills to deliver the solution exist on all new teams.

10. Push for Automation

If you are in a development environment where tools, automation and engineering practices are not currently being used, and they could be of value to your organization, then start investigating whether it is possible. Tools and automation aren’t cheap or easy to implement, but they dramatically encourage you and your teams to collaborate better and they enable the adoption of Scrum practices such as fast delivery of value.

Final Note

Be confident that your own creativity may help you unlock ways of practicing Scrum methodology without disrupting your organization’s practices.

You may or may not be able to implement all of the above actions but, as one Agile coach says, “it’s all about how YOU show up, how YOU are.” In the final analysis, your example, your enthusiasm, your courage will be the best you can offer.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, Theory of Agile

Scrum vs. Kanban vs. ADKAR vs. Kotter: Change Management

1 Comment

The battle of the organizational change management approaches!

Check out the presentation I did last night at Agile Mississauga Meetup.

20170208 Agile Mississauga Meetup – Change Approach Characterization Model

I describe a model for understanding change management approaches and deciding which ones to use for your situation.  I also look briefly at Positive Deviance and Appreciative Inquiry.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile coaching, Agile Management, coaching, How-To Apply Agile, Introduction To Agile, Links to Agile Info, Professional Development, scrum team improvement, Theory of Agile

How HR Can Save or Destroy Agile

Leave a comment

“Business engagement alone is a necessary but not sufficient condition for Agile to succeed”

It’s taken a while but now it’s well understood amongst seasoned Agile practitioners that Business engagement is necessary for successful Agile implementations. Just when we thought engaged Business owners were enough, we’re now realizing Business engagement alone is not sufficient. The impact of corporate shared services, especially Human Resources (HR), on Agile adoptions or transformations are often overlooked. In fact, Agile practitioners often bypass HR in their zeal to quickly change the way they work and the related people processes.

“Companies are running 21st century businesses with 20th century workplace practices & programs”

– Willis Towers Watson

It’s not just IT departments practicing Agile but 21st century businesses overall that are characterized by flatter organizations and an insatiable appetite for small ‘a’ agility. Agility that is pushing and breaking the envelope of current HR processes and tools. Agile individuals and teams are very vocal when it comes to calling out technical obstacles in their way. The same could be said when it comes to HR related obstacles that impact Agile individuals and teams. If we listen, here’s what we would hear:

  • “Can we team interview the candidate for attitude and fit?”
  • “I was an IT Development Manager. What’s my role now?”
  • “My manager doesn’t see half of what I do for my team. How can she possibly evaluate me?”
  • “With no opportunity for promotions in sight, how can I advance my career?”
  • “Why do we recognize individuals when we’re supposed to be focused on team success?”
  • “Charlie’s not working out. Can we as the team fire him?”

As the volume increases, how will HR and HR professionals respond?

“2016 will be the year of Agile HR … most HR teams have no clue what Agile HR means”

– HR Trend Institute

The reality is that most HR teams have no clue what Agile is, never mind how it will ultimately rock their world. Most Agile initiatives emerge from the grass-roots or are driven independently by IT functions with little to no involvement from HR. HR  sits on the sidelines and watches IT “do their thing”. There is a misconception that Agile exclusively falls under the IT domain; overlooking the fact that the core of Agile is about the people and culture – the sweet spots of the HR profession.

There are three significant change movements gaining momentum:

  1. Reinventing the way we work – whether it’s IT adopting Agile or an organization becoming more nimble.
  2. Reinventing HR – where HR is moving beyond its historical focus on basic people administration, compliance and transactions to a valued place at the executive table; ensuring context and alignment across the business to generate Customer delight.
  3. Reinventing organizations – as the level of human and organizational consciousness evolves from valuing meritocracy, accountability and innovation to valuing self-management, wholeness and evolutionary purpose. (See “Reinventing Organizations” by Frederic Laloux: http://www.reinventingorganizations.com/)

All three have the common denominator of people; an integral part along the entire timeline of each movement. As these three movements overlap – at the intersection – will be HR. So, who better to help navigate the emerging paths of each change than “the People’s people”?… otherwise known as “HR”.

An analysis of the Human Resources Professionals Association’s (HRPA) Competency Framework shown below can help guide which HR competencies will have the greatest impact (on a scale of 1 to 10) on Agile.

“How do we get HR started towards their destiny?”

If you’re an Agile team member, invite HR to start a conversation about what Agile is and how they can help you and the team.

If you’re an HR professional, here are some suggestions:

  • Learn about Agile
  • Visit with your Agile teams during sprint reviews or daily scrums
  • Talk to your friends and colleagues about their Agile experiences and challenges
  • Review in-progress HR process & tool changes through an Agile lens
  • Partner with IT and other Agile implementation stakeholders to guide the success of Agile

To help HR take the first step, here are some suggested Agile learning resources:

It’s time for HR to get off the sidelines and get in the game.  HR needs to be a “friend” to Agile, not perceived as a “foe”.

Borrowing from a Chinese proverb,

When the winds of change blow, some will build walls while others build windmills… the harnessing of your greatest natural resource, your people, into power.

Build windmills.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Kanban, Theory of Agile

How Kanban Saved Agile

6 Comments

In reality, Kanban isn’t actually saving Agile nor is it intended to, nor is any thoughtful and responsible Kanban practitioner motivated by this agenda. What I’m really trying to convey is how human thinking about the business of professional services (including software development) has evolved since “Agile” as many of us know it was conceived around 20 or so years ago. The manifesto is the collective statement of a group of software development thought leaders that captured some of their ideas at the time about how the software industry needed to improve. Essentially, it was about the iterative and incremental delivery of high-quality software products. For 2001, this was pretty heady stuff. You could even say that it spawned a movement.

Since the publication of the manifesto in 2001, a lot of other people have had a lot of other good ideas about how the business of delivering professional services can improve. This has been well documented in well known sources too numerous to mention for the scope of this article.

Substantial contributions to the discourse have been generated by and through the LeanKanban community. The aim of Kanban is to foster environments in which knowledge workers can thrive and create innovative, valuable and viable solutions for improving the world. Kanban has three agendas: survivability (primarily but not exclusively for the business executives), service-orientation (primarily but not exclusively for managers) and sustainability (primarily but not exclusively for knowledge workers). Kanban provides pragmatic, actionable, evidence-based guidance for improving along these three agendas.

Evolutionary Theory is one of the key conceptual underpinnings of the Kanban Method, most notably the dynamic of punctuated equilibrium. Evolution is natural, perpetual and fundamental to life. Long periods of equilibrium are punctuated by relatively short periods of “transformation”—apparent total and irreversible change. An extinction event is a kind of punctuation, so too is the rapid explosion of new forms. Evolutionary theory is not only a scientifically proven body of knowledge for understanding the nature of life. It can be also applied to the way we think about ideas, methods and movements.

For example, science has more or less established that the extinction of the dinosaurs, triggered by a meteor impact and subsequent dramatic atmospheric and climate change, was in fact a key punctuation point in the evolution of birds. In other words, dinosaurs didn’t become extinct, rather they evolved into birds. That is, something along the lines of the small dinosaurs with large feathers hanging around after Armageddon learned to fly over generations in order to escape predators, find food and raise their young. Dinosaurs evolved into birds. Birds saved the dinosaurs.

There has been a lot of social media chatter and buzz lately about how Agile is dead. It is a movement that has run its course, or so the narrative goes. After all, 20 years is more or less the established pattern for the rise and fall of management fads. But too much emphasis on the rise and fall of fads can blind us to larger, broader (deeper) over-arching trends.

The agile movement historically has been about high-performing teams. More recently, market demand has lead to the profusion of “scaling” approaches and frameworks. Scaling emerged out of the reality of systemic interdependence in which most Agile teams find themselves. Most agile teams are responsible for aspects of workflows—stages of value creation—as contributors to the delivery of a service or multiple services. Agile teams capable of independently taking requests directly from and delivering directly to customers are extremely rare. For the rest, classical Agile or Scrum is not enough. The feathers just aren’t big enough. Agile teams attempting to function independently (pure Scrum) in an interdependent environment are vulnerable to the antibodies of the system, especially when such interdependencies are merely denounced as impediments to agility.

Some organizations find themselves in a state of evolutionary punctuation (the proverbial sky is falling) that can trigger rapid adaptations and the emergence of local conditions in which independent service delivery teams can thrive. Most large, established organizations seem to be more or less in a state of equilibrium. Whether real or imagined, this is what change agents have to work with. However, more often than not, the typical Agile change agent seems adamant that the sky is always falling and that everyone accepting that the sky is falling is the first step to real and meaningful change. This is not an attitude held by Agile change agents alone. This is a standard feature of traditional 20th Century change management methods, the key selling point for change management consulting.

Naturally, most self-identifying “Agilists” see themselves as change agents. Many of them find themselves in the position of change management consultants. But the motivation for change can quickly become misaligned: Change needs to happen in order for Agile to work. If you are passionate about Agile, you will seek to bring about the environmental changes that will allow for Agile to thrive. We don’t need to follow this path too far until Agile becomes an end in itself. It is understandable then that for some, Agile appears to be a dead end, or just dead.

But if there is a larger, over-arching historical process playing out, what might that be? Perhaps it has something to do with the evolution of human organization. Perhaps we are living in a period of punctuation.

For my working definition of Kanban, please refer to my previous article 14 Things Every Agilist Should Know About Kanban (this contains links to the Kanban body of knowledge, including Essential Kanban Condensed by David J. Anderson and Andy Carmichael).

For my working definition of Agile, please refer to The Manifesto for Agile Software Development.

 

 

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Introduction To Agile, Links to Agile Info, Scrum Master, Theory of Agile

David Sabine: What Real Agility Means To Me

Leave a comment

Image

“Real Agility to me means being aware of and accepting of the present, in order to respond and chart new courses for the future,” David Sabine

My name is David Sabine. I’m a Real Agility Coach and have been thinking about what Real Agility means to me.

My introduction to Real Agility began in 2007 when the CTO of the college I was working at in Fort McMurray, Alberta brought in Mishkin Berteig as a third party consultant. Back then, I was a software developer and what I experienced then is still true today. The value of bringing in a third party to solve business challenges is immeasurable.

Time and time again, as I have been involved with companies, either in a training or a consulting capacity, I have found that a third party presence provides or creates a break-through. The purpose is not that I go to a company as a consultant and I bring my new ideas, as though I am the only one with new ideas.  What happens instead is that I visit a company and my presence, as a coach, opens the door for the internal staff to explore their own new thoughts, or concepts or possible solutions. So the ideas that are already in the company are just allowed to blossom a little bit in the presence of a third party,because this third party allows or creates a sense of permission, a sense of autonomy for those staff. They’ve been invited to explore concepts and they’ve been invited to think through their business problems from a different perspective and I am there just to reflect what they already have or what they already know.

That occurred when Mishkin Berteig visited the college in 2007, and that occurs every time I go and visit a company for training or consulting.

To really understand what Real Agility means to me, I’d like to tell you about how I came to software development in the first place beginning back in 1993 when I was starting university and was a freelance musician.

I had two passions at the time: the pursuit of music and the logic of programming. My computer tended to pay the bills, more so than being a freelance musician, so as a career path I guess I was drawn to software development and started to build my own products early on in 1996-1997. I was writing software for small business clients with the aim to eventually build a product on my own and release it for sale worldwide.

In 2000, I started to develop a product with a friend of mine. In 2001 we released it to other developers in the world. Our first sale of that product was in Belgium and for the next few years it sold worldwide. We had about 2000 websites that were using our product and it was translated into seven different languages by the community of users. It provided my friend and I with a reasonable income and a great opportunity. It was fun!

In 2006, I realized that my own growth as a computer scientist required working with others beyond this friend, to work in a team, in fact. I moved to Northern Alberta and worked in IT department for a college. As I mentioned, in 2007, the CTO, brought in Mishkin Berteig to provide us with a 3-day training course on Scrum. Quite immediately I loved it because I could see how it would provide us with a lot of opportunity to solve problems we were facing in an IT department and, secondly, it just seemed like a more human way to work. I was reflecting on all of these periods I had had as a musician, working with other musicians, and it just seemed like a better way to approach the creative endeavor than other project management methods that were in play at the time.

Since that time, I’ve been practicing them in a variety of settings and I’m more convinced now than ever that the Agile Manifesto provides us with a great solution space as we respond to business challenges. Recently I’ve decided not to be a developer or product owner but have decided to join Berteig full time and train and coach other teams.

So that’s the story of my personal evolution. My personal journey.

Looking back on that training I can see how I felt immediately that Real Agility was an alternative way of doing things.

I studied music since I was a child and music has always been a huge part of my life,and as a musician, one becomes aware of or familiar with continuous improvement. This is the same concept found in Real Agility. But with music it’s incremental, tiny, tiny increments of improvement over time. We respond to an audience. We respond in real time to our fellow musicians. We are always taking in input and that informs our performance of the music. As musicians, we spend a lot of personal time developing our craft. We spend significant time in performance so we can receive the audience feedback.

What I mean to say is that musicians are excellent examples of high performance teams and are excellent examples of creative excellence, who understand tactical excellence and what it means to get there.

When I joined Software development in a large, bureaucratic institution – the college – it was anything but natural for me. At that time, I was more than just a software developer. I was systems analyst, database admin and a variety of positions or roles. It just felt like an industrialized, mechanical environment where people were expected to behave as interchangeable units of skill. Work was expected to get done in the prescribed procedure. And decisions were expected only to be made by the smartest or the highest paid few and if you weren’t of that ilk, you were not expected to behave autonomously. You were expected to be just part of the machine and it felt very inhuman, as most people feel as a part of a large hierarchical bureaucracy.

When Mishkin facilitated the Certified Scrum Master training course in 2007, it just blew all those doors open. It reminded me that we can approach our work the way I had naturally approached it, as a creative individual who is capable of learning and wants to receive immediate feedback from audience or user, and who can make autonomous decisions about how to apply that feedback into the continuous development of software and systems and large infrastructure.

These business challenges are pretty common. They are delayed projects or projects that that blow the budget, or where a group of people are assigned to the project and they can’t possibly complete the scope of work in the time given. Or staff are demoralized, and how that expands through enterprises. There are many examples. The college where I was working suffered all of the most common issues and the one that hurt me the most or I felt the most was attrition. Dis-engaged staff. The reason for it was simple. The college had not presented with them a purpose or opportunity to be masterful. The extrinsic motivators, salaries and such, were just enough to keep people for a little while and then they would leave. And so the college at the time was experiencing attrition of 35-40% per year and that’s what I meant by inhuman.

“These Real Agility methods presented a change. In fact, people become centric to the purpose!”

When I read the Agile Manifesto I think that it provides us with solutions, and so if our current business problem or business circumstance is that we have disengaged staff who aren’t very productive and aren’t getting along well, then the Agile Manifesto reminds us that perhaps business people and developers can work daily throughout the project together. They can have continual interaction, and then individuals and their interactions become more valuable than the process and the organizational tools that have been put in their way. It reminds us that people should be allowed to work at a sustainable pace. We should build projects around motivated individuals. And that poses questions about how to do those things. What does it mean to be motivated, and how do we build projects around motivated people?

So Agile Manifesto presents us with some challenges, as a mental process, and then when we work through that we understand how it can inform good decisions about how to solve business problems.

“Real Agility to me means being aware of and accepting of the present, in order to respond and chart new courses for the future.”

In other words, Agility means being nimble, the ability to adapt to current circumstance, but more than that, Real Agility means that we should approach our work with the intention that we stay light-weight so that when our circumstances change we can adapt without a lot of inertial resistance. So there’s two components there. One is being able to adapt quickly, and being aware of present circumstance but the other is that we don’t want to take on weight and institutional mass, because that’s inertia, the status quo.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Engineering, Theory of Agile

Sabine’s Principle of Cumulative Quality Advantage

Leave a comment

Many organizations won’t survive the next decade. Of those that survive, even they are likely to be extinct before century’s end — especially the largest of contemporary organizations.

I was thinking today of a few essential adaptations that enterprises must make immediately in order to stave off their own almost-inevitable death.

With Regard to Business Strategy

  • Measure value delivered and make decisions empirically based on those data.
  • Strive toward a single profit-and-loss statement. Understand which value streams contribute to profit, yes, but minimize fine-grained inspection of cost.
  • Direct-to-consumer, small-batch delivery is winning. It will continue to win.

With Regard to People

  • Heed Conway’s Law. Understand that patterns of communication between workers directly effect the design and structure of their results. Organize staff flexibly and in a way which resembles future states or ‘desired next-states’ so those people produce the future or desired next-architectures. This implies that functional business units and structures based on shared services must be disassembled; instead, organize people around products and then finance the work as long-term initiatives instead of finite projects.
  • Distribute all decision-making to people closest to the market and assess their effectiveness by their results; ensure they interact directly with end users and measure (primarily) trailing indicators of value delivered. Influence decision-making with guiding principles, not policies.
  • The words ‘manager’ and ‘management’ are derogatory terms and not to be used anymore.
  • Teams are the performance unit, not individuals. Get over it.

With Regard to Technology

  • Technical excellence must be known by all to be the enabler of agility.
  • Technical excellence cannot be purchased — it is an aspect of organizational culture.

For example, in the realm of software delivery, extremely high levels of quality are found in organizations with the shortest median times-to-market and the most code deployments per minute. The topic of Continuous Delivery is so important currently because reports show a direct correlation between (a) the frequency of deployment and (b) quality.

That is, as teams learn to deploy more frequently, their time-to-market (lead time), recovery rates, and success rates all change for the better — dramatically!

I have a theory which is exemplified in the following graph.

Sabine’s Principle of Cumulative Quality Advantage Explained

As the intervals between deployments decrease (blue/descending line)

…quality increases (gold/ascending line)

…and the amount & cost of technical debt decreases (red area)

…and competitive advantage accumulates (green area).

Note: The cusp between red and green area represents the turning point an organization makes from responding to defects to preventing them.

This is a repost from David’s original article at tumblr.davesabine.com.

This post is inspired in part by these awesome texts:

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Links to Agile Info, Theory of Agile

VIDEO: What is all the buzz about agile?

Leave a comment

This short clip gives a great overview of where the idea of being agile came from, how it was used in software development first, and how it’s being used now.

“Remember: Agile’s success comes from working differently. Not from working faster.”

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Reference Information, Theory of Agile

Youtube Video: Paradigm Shift by Mishkin Berteig

Leave a comment

Many organizations are attempting to use Agile methods.  Banks, telecom companies, government agencies, and all manner of mid-size and small organizations.  Most of these attempts are limited in that they think of Agile as a solution instead of as a culture.  In this video, I explore the paradigm shift which is needed for long-lasting change.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, Scrum, XP and Lean, Theory of Agile

“Teams” Larger Than Eleven Are Not Scrum Teams

2 Comments

Mobbing Team

Scrum suggests the size of the Development Team (the Scrum Team members who perform the work of the Sprint Backlog) be between three (3) and nine (9) people. (The Scrum Master and Product Owner are not included in that count unless they are also executing the work of the Sprint Backlog.) To maximize cohesion and minimize complexity, it is important larger groups be split into smaller units or downsized.

Considerations for re-organizing into multiple Scrum Teams:

  • People executing the work may be best suited to decide optimal team size and composition. Adjustments to team composition will be most effective if the team members are trusted (and supported) to re-organize around their own work.
  • Groups larger than eleven people often naturally subdivide into smaller, cross-functional sub-groups; therefore it may be possible to carefully observe which team members interact regularly while getting work done and simply acknowledge those informal arrangements.
  • In order to minimize dependencies between teams, Scrum Teams whose mandates are to own discreet Products or systems are preferable to groups whose mandates are to support “components” of larger systems.
  • Organizations which currently employ Project Management methods ought to consider changing budgeting & staffing practices to align around Product delivery rather than Project Management. Doing so will make value streams transparent and bring clarity to Product-centric team mandates.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Theory of Agile

Face-to-Face Value

1 Comment

Linkedin has introduced a new app called Linkedin Lookup, advertised as “the fastest way to find and learn about your coworkers.”

If you don’t know who your co-workers are then your Enterprise has big problems, and a LinkedIn app won’t solve them. But Agile can…

The first Value in the Agile Manifesto reads: “Individuals and interactions over processes and tools.”

What does that mean? For some understanding, you might read this excerpt from: Applying Agile Management Value 1: (Agile Project Management For Dummies)

The first core value of the Agile Manifesto is to value individuals and interactions over processes and tools. When you allow each person to contribute unique value to your software development project, the result can be powerful.

… This emphasis on individuals and teams puts the focus on people and their energy, innovation, and ability to solve problems. You use processes and tools in agile project management, but they’re intentionally streamlined and directly support product creation. The more robust a process or tool, the more you spend on its care and feeding and the more you defer to it. With people front and center, however, the result is a leap in productivity. An agile environment is human-centric and participatory and can be readily adapted to new ideas and innovations.
If you do not know who your employees or co-workers are, if you are never with them when they are engaging in their work to note their individual styles and capacities, then you are part of the old corporate way of conducting business, and will not be able to succeed given the current needs that demand a more humanistic approach to problem-solving and increased production – in other words, needs that demand agility.

What does it take to introduce yourself to a co-worker on another floor? What does it take to encourage an individual or team struggling with a creative problem? What does it take to tell someone, face-to-face, their work is well done?

These small interactions can have a great effect on any individual. She/he will feel valued, needed, noticed, regarded, and will likely want to learn and work even harder to increase his/her potential.

In Forbes magazine, January 2015, Steve Denning wrote an interesting article that speaks to the value of “individuals and interactions over processes and tools. His piece is called ”Why do Managers Hate Agile?”

http://www.forbes.com/sites/stevedenning/2015/01/26/why-do-managers-hate-agile/
In it, he compares the vertical mindset and approach of corporations, which served them well one hundred and fifty years ago, to the horizontal approach that Agile offered in the late part of the 20th century as a response to changing needs in the world.

Denning writes:

“Agile, Scrum and Lean arose as a deliberate response to the problems of hierarchical bureaucracy that is still pervasive in organizations today: falling rates of return on assets and on invested capital, a dispirited workforce… and widespread disruption of existing business models.

…the world changed and the marketplace became turbulent. There were a number of factors: globalization, deregulation, and new technology, particularly the Internet. Power in the marketplace shifted from seller to buyer; average performance wasn’t good enough. Continuous innovation became a requirement; in a world that required continuous innovation, a dispirited workforce was a serious productivity problem. As the market shifted in ways that were difficult to predict, static plans became liabilities; the inability to adapt led to “big bang disruption.” In this turbulent context, the strengths of hierarchical bureaucracy evaporated. In this context, businesses and institutions requires continuous innovation.”

Social media apps can be fun and helpful, but they cannot replace human face-to-face interaction. Think about Agile’s first value as a place to begin.

 

 

 

 

 

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Article Reviews, How-To Apply Agile, Theory of Agile

Article Review: Thinking About the Agile Manifesto

Leave a comment

Often times, as I’ve been researching about agile methods and how to apply these to create real and sustainable change in an organization, I come across reference to the Agile Manifesto. I list it here today for those who are new to the field or who are getting back to the roots after trying a few things with different-than-expected results. It is an instrumental document. The values and principles listed here truly do shape the way agilists think and operate and to some degree or another the results appear to be better than before this founding document was introduced. So here is my “hats off” to this remarkable item which plays a pivotal role in cultural transformation.

The four key values are:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Personally, I find the first one the most meaningful of all. When we value individuals and interactions over process and tools we are truly improving in leaps and bounds in creating collaborative environments which are continuously improving.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Theory of Agile

What You Need To Know About Disruption

Leave a comment

This information was presented by John Hagel in a Scrum Alliance webinar, April 12, 2016. These are my notes plus a few thoughts.DSC_0616.

The idea of Disruption in business was popularized in ‘97 in a book by Clayton Christensen. What is disruption? It occurs when most of the leading incumbents (in business, politics, technology, etc) are displaced by a new approach that is challenging to replicate. Disruption can usually be quickly seen in a change in economic factors or a change in mindsets.

There are 5 aspects of disruption to be aware of:

1. it’s happening across every industry

2. well-managed firms don’t make you safe from disruption

3. most firms/ businesses did not see it coming, i.e. newspaper industry

4. disrupting companies are not themselves immune from disruption

5. there are multiple-patterns or inter-related patterns of disruption

Most companies focus on their high-value estimates; their low-value customers don’t seem to be a threat. But as low-value items or services steadily improve, we see high-value customers shift to that. Firms must become Agile and be able to adjust on-the-fly to new technologies; they should not focus on adding improvement just to high-value things.

John Hagel clarified that disruption is a universal phenomenon – “the story of the century.” Many companies are not weathering the storm. The average life of a leading company in the ‘50’s was 62 years – now it is 18 years.

This is due to a fundamental shift in value creation, whereby consumers are gaining more power with more information and options, and knowledge workers are gaining more power in that talent has greater visibility, and higher wages can be continually demanded.

Hagel’s research shows that there are patterns that can act as lenses through which disruption can be viewed. The first pattern relates to the transformation of value and economics. For example, the digital camera became a huge disruption to the photography industry, but now itself has been disrupted by the ability to embed digital cameras in cellphones. The second pattern relates to “harnessing network effects;” the more participants that join, the more value is created. This pattern is more enduring and challenging to disrupt.

In your industry, what would you look for to understand market vulnerability? Would it be through product pricing, product modularity, demand characteristics, or supply constraints? If you assess your industry, which catalysts are the most important to understand to deal with disruption?

My personal thought is that, given the organic nature of the world’s systems, whatever disruptions are trending in the world around us, sooner or later they will have an effect on most businesses and organizations.

Disaster can be staved off by becoming more Agile in your organization. Agile will help everyone respond more quickly and with flexibility to disruptions. In fact, Agile itself has become a disruptive factor for outmoded ways of doing business.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Berteig
Upcoming Courses
View Full Course Schedule
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Mar 31
2023
Details
Real Agility Management Track - Practitioner I (RA-MT-LA)
Online
C$7950.00
Apr 3
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 4
2023
Details
Advanced Certified ScrumMaster® (ACSM)
Online
C$1795.00
Apr 5
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1895.00
Apr 11
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 14
2023
Details
Win as a Manager with Your New Agile Coach: ChatGPT
Online
C$0.00
Apr 14
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 17
2023
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
Apr 18
2023
Details
Kanban for Product Owners (ML-KPO)
Online
C$495.00
Apr 19
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 21
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 25
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1895.00
Apr 26
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 28
2023
Details
Win as a Manager with Your New Agile Coach: ChatGPT
Online
C$0.00
Apr 28
2023
Details
Advanced Certified Scrum Product Owner® (ACSPO)
Online
C$1525.75
May 3
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
May 5
2023
Details
Kanban Systems Improvement® (KMPII)
Online
C$1610.75
May 10
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
May 12
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
May 12
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1100.75
May 16
2023
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
May 16
2023
Details
Kanban for Product Owners (ML-KPO)
Online
C$495.00
May 17
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1610.75
May 17
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
May 19
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
May 19
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
May 26
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
May 26
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1610.75
Jun 7
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 9
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 9
2023
Details
Kanban System Design® (KMPI)
Online
C$1610.75
Jun 13
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1610.75
Jun 14
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 16
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 16
2023
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
Jun 20
2023
Details
Kanban for Product Owners (ML-KPO)
Online
C$495.00
Jun 21
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Jun 21
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 23
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 23
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 30
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 30
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1610.75
Jul 5
2023
Details
Kanban Systems Improvement® (KMPII)
Online
C$1610.75
Jul 11
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1610.75
Jul 12
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Jul 19
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Aug 15
2023
Details