Tag Archives: change

Foundations of Excellence

I was thinking about the concept of becoming excellent at something.  My son is a budding artist.  He and I had a conversation a few months ago about talent or aptitude.  I said to him that I felt that aptitude is only latent: you need to put effort into something in order to expose your talent.  He was concerned that he didn’t have any aptitude because he had to work so hard to become better at drawing.  I compared him to myself and my brother, Alexei: when we were growing up, we both put a lot of effort into drawing.  Quickly, I fell behind my brother in skill.  He clearly had aptitude.  But he also put in a lot of effort into exposing that talent.  I was reminded of all this because my son is struggling with math.  He has aptitude, but he hasn’t put much effort into it.  I was wondering why?

Then I realized that aside from aptitude and effort, two more things need to be in place to achieve excellence: willingness and confirmation.

Willingness is the internal drive, usually motivated by an unconscious set of factors, but sometimes also coming from a strong conscious decision.  Willingness can come from unusual combinations of circumstances.  I was extremely willing to learn mathematics in my youth.  This came from two experiences.  One, in grade 2, was when my teacher told me that I shouldn’t be learning multiplication (my dad had taught me while on a road trip).  I was upset that I shouldn’t be able to learn something.  Then, in grade 3, I had a puppet called Kazir (a gift from my babysitter who told stories about space adventures with Azir and Kazir the Baha’i astronauts).  I brought Kazir to school one day and while doing math problems, I pretended that Kazir was helping me.  Suddenly I found math easy.  These two events plus a few others contributed strongly to my desire, my willingness to learn math.

Confirmation is the set of environmental factors that helps keep us on a path of learning.  These environmental factors are sometimes mimicked in the corporate world with bonuses and gamification, but these are really distant shadows of what confirmation is really about. Confirmation is when the stars align, when everything seems to go right at just the right time, when the spirit inspires and moves you and the world to be, in some way, successful.  The trick about confirmation is that success is not usually about monetary success.  It’s usually about social, relational or even sacrificial success.  As an example, when I was in grade 7, I was chosen with a small group of people in my class to do accelerated math studies.  This was a great honour for me and was a confirmation of my interest in math.

In organizational change, and in particular in changing to an Agile enterprise, we need to be aware that excellence requires that these four factors be in place.  Aptitude is, to some degree, innate.  We can’t trick people to have aptitude.  If someone is just fundamentally bad at a certain thing, despite vigorous educational efforts, then that person likely doesn’t have the aptitude.  Effort is about both having time and resources, but also, then about willingness.  And willingness, in turn, can only be sustained with confirmation.  Too much discouragement will break a person’s willingness.  The Agile enterprise requires a great number of skills and abilities that are not normally part of a person’s work environment prior to attempting to adopt Agile.  Keeping these four things in mind can help people in an organization to reach excellence in Agility.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Book List for Enterprise Agile Transformations

Leaders of Agile Transformations for the Enterprise need to have good sources of information, concepts and techniques that will guide and assist them.  This short list of twelve books (yes, books) is what I consider critical reading for any executive, leader or enterprise change agent.  Of course, there are many books that might also belong on this list, so if you have suggestions, please make them in the comments.

I want to be clear about the focus of this list: it is for leaders that need to do a deep and complete change of culture throughout their entire organization.  It is not a list for people who want to do Agile pilot projects and maybe eventually lots of people will use Agile.  It is about urgency and need, and about a recognition that Agile is better than not-Agile.  If you aren’t in that situation, this is not the book list for you.

Culture

These books all help you to understand and work with the deeper aspects of corporate behaviour which are rooted in culture.  Becoming aware of culture and learning to work with it is probably the most difficult part of any deep transformation in an organization.

The Corporate Culture Survival Guide – Edgar Schein

Beyond the Culture of Contest – Michael Karlburg

The Heart of Change – John Kotter

Management

This set of books gets a bit more specific: it is the “how” of managing and leading in high-change environments.  These books all touch on culture in various ways, and build on the ideas in the books about culture.  For leaders of an organization, there are dozens of critical, specific, management concepts that often challenge deeply held beliefs and behaviours about the role of management.

Good to Great – Jim Collins

The Leaders’ Guide to Radical Management – Steve Denning

The Mythical Man-Month – Frederick Brooks

Agile at Scale

These books discuss how to get large numbers of people working together effectively. They also start to get a bit technical and definitely assume that you are working in technology or IT. However, they are focused on management, organization and process rather than the technical details of software development. I highly recommend these books even if you have a non-technical background. There will be parts where it may be a bit more difficult to follow along with some examples, but the core concepts will be easily translated into almost any type of work that requires problem-solving and creativity.

Scaling Lean and Agile Development – Bas Vodde, Craig Larman

Scaling Agility – Dean Leffingwell

Lean Software Development – Mary and Tom Poppendieck

Supporting

These books (including some free online books) are related to some of the key supporting ideas that are part of any good enterprise Agile transformation.

Toyota Talent: Developing Your People the Toyota Way – Jeffrey Liker, David Meier

Agile Retrospectives – Esther Derby

Continuous Delivery – Jez Humble, David Farley

The Scrum Guide – Ken Schwaber, Jeff Sutherland, et. al.

The OpenAgile Primer – Mishkin Berteig, et. al.

Priming Kanban – Jesper Boeg


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Agile Framework: Agile Values and Principles, The Agile Toolkit, The Agile Organization

When I am speaking with executives, ScrumMasters and other leaders of change in organizations, I often present a simple 3-layer model to understand the relationship between the various moving parts in the Agile Framework:

  1. The Agile Values and Principles – These describe the culture and, in the Agile Manifesto, are the definition of the word “Agile” as applied to software development. I didn’t write the Agile Manifesto so I don’t get to re-define the word Agile.  To give an example: in the manifesto it says “The best architectures, requirements and designs emerge out of self-organizing teams.”  As a former enterprise architect at Charles Schwab, I struggled with what I saw as incredibly wasteful up-front architectural activities when I knew that developers would (sometimes) ignore my glorious ivory-tower plans!  Therefore, if you are still doing up-front architecture and forcing your teams to comply to that architecture, you aren’t Agile.  Therefore, as an individual, a team or an organization, you need to make a conscious decision to “BE” Agile or not… and if you decide not, then please don’t call yourselves Agile.
  2. The Agile Toolkit – There are many hundreds of distinct tools in the Agile toolkit including Scrum, OpenAgile and other “large” Agile methods, as well as the Planning Game, Product Box, Test-Driven Development and other “small” Agile techniques.  Any group of people trying to BE Agile, will need to use dozens or even hundreds of different Agile tools.  I call them tools because the analogy with construction tools is a very good one.  Scrum is like a hammer.  But you can’t do much with just a hammer.  Scrum is a great, simple tool.  But you always need other tools as well to actually get stuff done.  All the tools in the Agile Toolkit are compatible with the Agile Values and Principles.  Even so, it is possible to use the Agile Tools without being Agile.  A Scrum team that never gets together face-to-face is not an Agile team: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”  (Video conferencing doesn’t count.)
  3. The Agile Organization – When you start using a tool, there is a learning period.  We start by being conscious of our incompetence and as we persist, we become competent… but it isn’t natural or habitual yet.  Eventually, with continued use, we become unconscious of the tool.  IDE’s and version control are like this in most organizations: we don’t even think about them!  But getting through that initial stage requires us to change; to develop new skills.  This process usually requires discomfort or pain (including psychological pain).  An organization attempting to BE Agile and to use many of the tools in the Agile Toolkit will need to make many changes and often these will be difficult.  For example, incorporating the Product Owner role from Scrum into your organization requires new role definitions, new performance evaluation practices and criteria, new compensation systems, new communication and reporting mechanisms, new authority and accountability processes, etc. etc.  All of the changes required are about creating Enterprise Agility throughout the whole organization, beyond just software or IT.  These extensive changes are often started in a very ad hoc manner, but at some point they need to become systematic.  This is an important decision point for executive management: are we going to be Pragmatic about our Enterprise Agile adoption, or are we going to be Transformative about our Enterprise Agile adoption.

All of this is summarized in this graphic:

The Agile Framework [PDF]

I sometimes also call this the “Agile Ecosystem” since it is a constantly evolving set of ideas (processes, tools, resources) that does not have a clearly defined boundary.  For example, the technique of Value Stream Mapping comes from Lean manufacturing but has also be broadly adopted by Agile practitioners.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

21 Tips on Choosing a Sprint Length

Many teams that I work with choose their Sprint length without too much thought.  Often enough, that’s okay and it works out.  But, in some cases, it helps to think clearly and deeply about what length of Sprint to choose.  Here are 21 tips on choosing a Sprint length.

  1. Don’t ever go longer than 4 weeks… if you do, by definition it’s not a Sprint anymore.
  2. Scrum is about fast feedback – shorter Sprints mean faster feedback.
  3. Scrum is about continuous improvement – shorter Sprints give a team more opportunities to improve.
  4. High-performance teams need pressure to form – shorter Sprints provide pressure.
  5. Each Sprint is, ideally, an independent project – longer Sprints may make it easier to get a potentially shippable product increment truly done every Sprint.
  6. “False” Sprints such as “Sprint 0” or “Release Sprints” may feel necessary if your Sprint length is too short – try to avoid the need for false Sprints.
  7. If you have lots of interruptions that are disrupting your Sprint plans, shorten your Sprints to match the average frequency of interruptions… and then just put them on the backlog.
  8. If you feel like you team starts out by working at a leisurely pace at the start of a Sprint and then “cramming” at the end of the Sprint, then shorter Sprints will force the team to work at a more even pace.
  9. Don’t lengthen your Sprint to fit the “size” of your Product Backlog Items… instead, get better at doing “splitting” to make the items smaller.
  10. Small failures are better than large failures, shorter Sprints help.
  11. If you are using Agile Engineering practices such as TDD, you should probably be able to do Sprints that are 1 week in length or less.
  12. 2-Week-long Sprints are most common for IT and software product development.
  13. Most Scrum trainers and coaches recommend Sprints to be 1 or 2 weeks long.
  14. Teams go through the stages of team development (forming, storming, norming and performing) in fewer Sprints if the Sprints are shorter.  E.g. 5 Sprints if they’re 1 week long, but 20 Sprints if they’re 4 weeks long.
  15. If your team has trouble finishing all the work they plan for a Sprint, make the Sprint shorter.
  16. Every Sprint should be the same length for a given team so don’t let your Sprints get longer just to “get everything done”.
  17. Experiment with extremely short Sprints to see what is possible: 1-day long, for example.
  18. If you are doing a project with a fixed release date/end date, then make sure you have at least 6 Sprints to allow for sufficient feedback cycles.  More is generally better which means shorter Sprint lengths.
  19. If you are working on a product, consider Sprints that allow you to release minor updates more frequently than your main competitors.
  20. Sprints need to be long enough that Sprint Planning, Review and Retrospective can be meaningful.  A 1-day Sprint would allow a maximum of 24 minutes for Sprint Planning, 12 minutes for Review and Retrospective each.
  21. When a team is new, shorter Sprints help the team learn its capacity faster.

Author’s Note: this is one of those articles where I thought of the title first and then worked to make the article meet the promise of the title.  It was tough to think of 21 different ways to look at Sprint length.  If you have any suggestions for items to add, please let me know in the comments (and feel free to link to articles you have written on the topic). – Mishkin.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Real Agility Program – Leadership Transformation Team

One of the main components of our Real Agility Program for enterprise Agile transformations is the Leadership Development track.  This track is a series of monthly leadership meetings with one of our consultants to help them establish their Leadership Transformation Team.  This team is based in part on the concept of a guiding coalition from John Kotter’s work (see “Leading Change“), and in part on Edgar Schein’s work on corporate culture (see “The Corporate Culture Survival Guide“) as well as our own specific experience on successful Agile transformations in organizations.

The very first thing, of course, is to establish who should be on the Leadership Transformation Team.  There are six major categories from which the team must find representatives:

  1. The Executive Sponsor, for example the CIO
  2. Business Management, for example an SVP of Sales or Product Development
  3. Process Management, for example the head of the PMO or Compliance
  4. Technology Management, for example VP of Technology or Development
  5. Human Resources, for example a Director of Staff Development and Training
  6. and Apprentice Agile Coaches / Agile Champions

In total, the number of people on this team should be no more than 12, but smaller is better.

Once established, this Leadership Transformation Team must execute on three core responsibilities in perpetuity:

  1. Urgency and Vision: constant, strong, repetitive, prominent communication of the reasons for change and a high level view of how those changes will happen.
  2. Lead by Example: use of an Agile approach to run the Leadership Transformation Team’s work – we recommend OpenAgile for the process, but Kanban may also be used.
  3. Empower Staff: focus on removing obstacles by making structural changes in the organization, helping staff master standard Agile processes and tools, and eventually, creating innovative Agile approaches customized for the organization.

This leadership support is a critical success factor for an Agile Transformation.  One of the first steps in our program for this team is to help with the creation of the team’s plan for the transformation.  This plan can be derived from an number of sources including assessment work, but includes a number of standard items that must eventually be addressed for a successful transformation.  At a high level, these include:

  • Hiring, performance evaluation and compensation
  • Reporting relationships
  • What to do with project managers, business analysts, testers and certain middle managers
  • Key metrics and processes for measuring progress
  • Technology and physical environment
  • Vendor relationships and contracts
  • Compliance, regulation and documentation

Many of these items are multi-year change efforts that need to be closely guided and encouraged by the Leadership Transformation Team.

One final point about the Leadership Transformation Team needs to be made: the work they do must not be delegated to subordinates.  If something is part of their three core responsibilities, it must be handled directly by the members of this team.  Therefore, the team members need to allocate a significant percentage of their time to the effort.  Usually 20% is sufficient to get started.  The proportion may wax and wane slightly over time, but if it gets too low, the Leadership Transformation Team will lose touch with the transformation and the risk of it going bad increases substantially.

See also our article about the Recommendations component of the Real Agility Program.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Transformation and the Chasm

In his book “Crossing the Chasm“, Geoffrey Moore describes the difficulty of creating a popular new product due to a conceptual “chasm” between the first people who adopt a new product and those who come later.  He describes five types of people in relation to how they adopt new products:

  • Innovators – always actively seeking out and trying cutting edge new products.
  • Early Adopters – excited to try new things, but after the worst “bugs” have been removed.
  • Then there is the Chasm – many products fail here.
  • Early Majority – willing to try new things but need strong testimonials or real-world proof.
  • Late Majority – require time-tested proof before they will adopt a product.
  • Laggards – resistant to change and hesitant to adopt anything without strong personal incentives.

This product adoption behavior also applies to new ideas in general, and of course, to Agile Transformation [Agile Transformation vs. Agile Adoption] in particular.

Implications of the “Chasm” Model

An organization attempting to do an Agile Transformation [Kotter’s 8-Step Change Model] should understand how to use this model to ensure long-term success.  This diagram illustrates the concepts (click on it to see it full size):

First, the organization should start the transformation by finding the innovators and early adopters.  These people can then be recruited to run the initial pilot projects.  They will be enthusiastic and will typically adapt themselves to the new behaviors and thinking patterns required by Agility.  If they are properly supported by managers, they will also be successful – at least within the bounds of a limited pilot environment.  Success here will mean that the pilot projects deliver value, use feedback effectively, and the participants (team members and stakeholders) will be happy with the results.

In this stage, it is best to avoid putting people on the teams who are from the early majority, late majority or laggards groups.  These people will tend to drag on the results of the pilot projects.  This is a common mistake in running a pilot program and leads to discouraging results.  One way to help filter between these two groups is simply to ask for volunteers for the pilot projects.  Innovators and early adopters will be much more likely to volunteer for a new initiative.

After the pilot projects have shown some good results, the next step is to go the general roll-out.  In this step, you are now working with the early and late majority.  These people need much more substantial support for a change of this nature.  They will require intensive training, and hand-holding in the form of coaching and mentoring.  This hand-holding can come partially from your innovators and early adopters.  Some of the participants in the pilot projects will have the desire to share their success.  From these, you need to carefully select and prepare a few who will act as internal coaches.  If you are a small organization or if you wish to do your transformation quickly, you will likely need to hire coaches from outside your organization as well.

The early and late majority require evidence of benefits and reassurance that risks are minimal or can be mitigated.  This evidence partially comes from your pilot projects.  However, this may not be sufficient.  There are two other important sources of evidence for this group: the leadership team and external experts.

The leadership team must be committed to the change to agility and can demonstrate this commitment by doing their own management work as an agile team.  The exact details of the agile process do not need to be identical to that of the staff teams, but it should be recognizably similar.  As well, this “Agile Transformation Team” must make itself very visible during the general roll-out.  This can be done with communication and by taking up visible residence in a central conference room or bullpen.  As well, this Agile Transformation Team must work diligently to remove obstacles that are raised by staff teams during the general roll-out.

The second source of evidence comes from external sources.  Published case studies are one valuable source.  However, there is a huge value in a visible management investment in external support from recognized experts.  This can be in the form of training, coaching, consulting as well as informal “lunch-and-learn” meetings, town hall meetings and the like.  When engaging experts, it is imperative that the Agile Transformation Team act on their advice otherwise the early and late majority will take that as a sign of hypocrisy.

The final stage of a roll-out is to deal with the laggards.  For the most part this is a do-or-die proposition for these people.  Either get with the program and engage like a committed employee or leave the organization.  If your organization is large enough, you will likely have observed some of these people leaving the organization in the general roll-out.

For some organizations, this transformation process can take many years.  An organization with thousands of people should expect to be working on the pilot projects for at least a year, the general roll-out for at least three years.  Often it will be longer.  Good luck on your agile transformation effort!


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Transformation vs. Agile Adoption (being vs. doing)

Agile methods are now popular enough that the Project Management Institute has officially recognized them in a number of ways including setting up an agile project management community for PMI members.  This is a good sign, and I re-joined the PMI as a result.  However, there is still a big gap between an Agile adoption and an Agile transformation. Between doing agile methods for project management and transforming your organization to become agile in all aspects of its work.  Most people are “doing” and “adopting” agile, not doing the deep transformation.

For some years now, the premise I have been working on is that agile methods are actually all about learning.  They aren’t about product delivery.  Rather, product (or service) delivery is the context for learning.  What does this matter?

Let’s imagine two similar organizations, Abacus and Brightstart.  Both organizations want to improve the way they are working.  In fact, they both see many similar opportunities in terms of efficiency gains, productivity gains, and improvements in customer satisfaction and employee morale.  Abacus is headed up by Alex who is a visionary leader whereas Brightstart is headed up by Brit who is a hard-nosed bottom-line kinda person.  Now just to make this interesting, let’s pretend that Alex doesn’t understand Agile and just wants to use an agile method as a way to improve the delivery of projects at Abacus.  Brit, on the other hand, has some trusted advisors who have insisted that agile be treated as a fundamental transformation in the way Brightstart does business.  What happens?

Abacus

Alex gets a staff member to attend some Scrum training and launch an agile pilot project.  Stakeholder satisfaction improves because of the frequent feedback.  Some agile best practices such as timeboxing and prioritized user stories are easily adopted but others are harder.  In particular, some of the obstacles uncovered by the team are related to the corporate culture of consensus-building which Alex considers to be a non-negotiable part of the organization.  Abacus is infused with the values and personality that Alex has brought to the organization as its founder.  So when the team had trouble getting clarification on its work because the consensus-building process was taking too long, Alex simply told them to move on to less important work and come back to the other stuff when it was “ready”.

Over time, there are modest improvements in productivity and customer satisfaction at Abacus, and most of the project work is done with an agile approach using several agile “best practices”.  But any time a team encounters an obstacle related to the culture of the organization, the team loses.  Gradually, agile is treated as just another method, just another tool that may or may not be applicable to the work being done.

Brightstar

Brit researches Agile methods deeply and comes to understand that there is a process component, but also a meta-process component.  Brit decides that the potential benefit is huge: multiplying productivity, increasing morale enormously, and becoming a leader in the marketplace… but that the level of effort to get there is also large.  Agile is not a “silver bullet“.  Truly doing agile requires a deep cultural change in an organization. Brit is fully aware that changing cultures is enormously difficult.

Brit decides that all work throughout the whole organization must take on an agile culture.  This is a culture that allows for experimentation and regular reflection and learning.  As well, Brit knows that like an athlete training for a major sporting event who gets a top-notch coach, Brightstar will also need a coach.  Internally driven culture change is even more difficult and since Brightstar isn’t in deep crisis, there isn’t as much motivation for staff to fundamentally change the way they work.  A coach will help to keep the motivation, vision, and encouragement flowing so that the corporate change will be sustainable.

Brit decides that the fundamental aspects of agile that need to be put in place are the timeboxed cycles of work that include a pause for reflection, learning and planning.  All types of work can be done in that framework.  The coach is responsible for helping the organization adopt this cycle of work and keeping at it until it becomes like a perfectly regular healthy heartbeat for the whole day organization. (See “Defibrilation” below…)

Finally, Brit announces to the organization that no opportunity for learning and improvement will be denied.  Over the course of several months, this is demonstrated by several interesting incidents where staff suggestions for obstacles to be removed are acted upon quickly and decisively.  Not every suggestion results in real improvement, but all the employees quickly get the message that the environment of learning is real, and the pace of suggestions increases as does the level of individuals taking initiative to make changes directly.

Within a year, productivity at Brightstar has soared.  There is an initial bump in staff turnover as some people who were there with an “it’s just a job” attitude moved on.  After the first year, employee staff turnover rates have decreased substantially, and can mostly be attributed to changes in personal circumstances such as marriages and deaths.

Brit gets it, and is willing to be hard-nosed about learning.  Learning about product, process and people.

A Plan for Agile Transformation

I’ve worked with quite a number of organizations trying to adopt agile and trying to do agile transformations.  In that time, I’ve seen some patterns.  I would like to describe the high-level pattern of what an organization does to make a successful agile transformation.  This overall plan must not be seen as a rigorous step-by-step procedure, thus using the term “wave” instead of “step” or “phase”.  It can be visualized thus:

Agile transformation over time

Step One: Decision

The leader of the organization decides that agile is more than just another method of project management or product development, and that the vision of an agile organization is worth the effort to make a deep transformation throughout the entire organization.

Wave One: Just Start

The leader engages trainers/coaches to do the following things roughly simultaneously:

  • Introduce _everyone_ in the organization to agile concepts
  • Start _everyone_ in the organization using the agile meta-process
  • Start an Agile Transformation Team made from members of upper management to guide the overall transformation
  • Do initial cultural and process assessments to track progress over time

Wave Two: Capacity Building

The coaches and the Agile Transformation Team work with employees to develop a sufficient number of people who are capable agile facilitators.  They learn about agile methods more deeply: practices, principles, variations, techniques, and tools.  They learn to be effective facilitators who have the trust of their co-workers.  These facilitators then become responsible for ensuring that everyone else is using the agile meta-process for effective learning and simultaneously applying appropriate agile practices.

Wave Three: Sustainability

Finally, the coaches work with the Agile Transformation Team to help a relatively small number of employees to become internal coach/trainers.  These are the people who will take over from the external coaches.

As an ongoing assistance, the coaches should be working in a consultative capacity as the organization struggles with obstacles, restructuring, and the deeper culture changes.  Like any change effort, there are five critical components: sponsorship, communication, training, support and strategy.  The coaches should be advising the Agile Transformation Team and management on how these five components can best be handled for the agile transformation.

* BERTEIG Project Defibrilation:

Imagine you are doing surgery – a routine tonsillectomy on a father of two young girls. His name is Dan. Something goes wrong with the anesthesia and his heart goes nuts. The defibrillator is brought out, the paddles applied to Dan’s chest and you yell “CLEAR!”. You trigger the defibrillator, but nothing happens, just a small clicking noise. The technician quickly checks the machine, and everything looks okay. You try again. “CLEAR!” There’s a small buzzing noise and your patient’s body trembles slightly. You put the paddles down, and, getting frantic, yell at the nurses to “go find another defib machine, NOW!!!”. Thirty agonizing seconds pass. Dan’s vital signs are deteriorating. One of the nurses rushes into O.R. with a cart with another defibrillator machine on it. Everyone works like a well-oiled machine to set it up. Another fifteen seconds pass. It charges up and you apply it again to the chest of this young father. “CLEAR!” There’s a huge electrical discharge and Dan is killed instantly. It takes a few more minutes for him to be officially pronounced dead.

Is this how projects are run in your organization?

If this had been a description of a real event, you would be furious and bewildered. You would sue the hospital for buying shoddy defibrillators. You would sue the company that made them. You would demand that the defibrillators work better – one hundred percent of the time would be about right!

Let’s stop running projects this way. Traditional project management practices are like unreliable defibrillators. They work about 30% of the time. Agile is the only known reliable defibrillator for your organization’s heart.

Like a defibrillator, knowing how and when to use agile properly is still hard. That’s where we come in. We’re experts in using agile methods to fix the heart of your organization.

Contact us before your organization flatlines.

info@berteig.com
+1-800-215-2314


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Professionalism and Agility

Recently, I have been reading Outliers by Malcolm Gladwell. Fascinating reading. In this book, Mr. Gladwell chronicles some of the backgrounds of top professionals in artistic, sport and business endeavors. He tried to determine why these individuals/groups have accomplished so much in their lives and why they are in the top of their profession. Tiger Woods, Bill Gates and the Beatles are a few of the many professionals he examines. There should be no doubt in your mind that Tiger Woods is the top golfer, Bill Gates is a very successful entrepreneur, and the Beatles are a prolific band.

Please forgive me Mr. Galdwell if I summarize and distill your findings into a few short sentences. The answer is 10,000 hours. Each of these individuals or groups put 10,000 hours into their chosen profession before they arrived at the top. They viewed their professions differently, were passionate about what they did and behaved differently when learning their profession. I am not suggesting you need to work for 10,000 hours before you are successful. I am suggesting if you adopt the same methods they do, you will increase your chance of success.

As I observed these top professionals, I began to see similarities in a number of areas. They seem to share a comfort in their ability to grow and develop. I am not sure they set out to be the top but they certainly thought they would overcome what life threw at them and they trusted their own capacity to excel. I have found that giving yourself a steady message of what is possible helps you deal better with life and to overcome all the negatives around us. As an example, I seldom read the newspaper or watch the news, for this barrage of negative messages affects my outlook of what is possible. It seems to me that these top professionals insulate themselves from negative messages as well.

Next, they have incredible self discipline skills. They practice their profession with passion. They don’t believe in luck as much as they believe in hard work. This is where the 10,000 hours come into their development. They are constantly practicing to improve and master their profession. The top professionals did not achieve their position through luck, they attained the position through hard work.

To summarize, their methods are to be positive about your ability to cope with the future, give yourself positive messages, be disciplined about mastering your profession and be prepared to work hard to achieve the position of the professional.

There is a quote I like that was told to me by a businessperson from Jamaica. When asked his view of life, he said “I refuse to be held hostage by circumstances!” The top professionals choose their future and are agile as they cope with what life offers.

It seems to me another reason why these individuals are so successful is that they were very agile in their approach to life. They created their future rather than follow others. Through their own personal agility they made the right decisions to gain a top position in their chosen profession.

So the question I have been wrestling with is this: If they can be the top, then why not me? What is holding me back? Well, if you have ever spent time with me, or read any of my books, you would know the answer. The only thing holding me back is me. Can I get better? Yes, I can. Can I work harder? Yes, I can. Can I be more successful? Yes, I can. Can I be more agile in my approach to life and its challenges? Absolutely yes!

So how about you? In these troubled economic times, we have an opportunity to re-invent ourselves. The best way to survive and thrive from our current situation is to build the future we desire. Rather than expending a lot of energy worrying about your current situation, you should be taking that energy and using it to take charge of your future and build a new reality. Approach whatever life throws at you with agility. I believe success is a choice. Make good choices and everything is possible.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Cool Blog – SustainabilityCulture.com

One of our partner organizations, HBI Leadership, has launched a blog called SustainabilityCulture.com.  Check it out!


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Benefits: Five Essential Reasons to Try Agile

Although there many other benefits of agile, and although those provide us with other reasons to try agile, the five essential benefits of agile are:

Rapid Learning – disciplined application of the scientific method to explore the best ways to deliver valuable results.

Early Return on Investment – opportunity to use the results of work starting with the work delivered at the end of the first iteration.

Satisfied Stakeholders – engagement in the process in a way that allows meaningful contributions from all stakeholders.

Increased Control – mechanisms to track/measure and therefore steer the direction that work is going so that it meets goals.

Responsiveness to Change – processes, tools, roles and principles that allow a team and an organization to embrace change rather than reject, control or suffer from change.

These reasons are sufficient and apply to operations work, project work and open-ended research work, whenever humans are involved. The above links take you to more detailed descriptions of each of these benefits.

What are some of the other benefits of agile?


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Change is Natural – “Embrace Change”

Kent Beck’s book “Extreme Programming Explained : Embrace Change” provides a good introduction to how software development can embrace the constant change that affects our world. Some of the practices he introduces are very software-specific. However, the overall basic message is sound and provides a foundational principle for all agile work. (By the way, the book is excellent.)

Change really does occur everywhere. Change is constant. A google search for “embrace change” or “change is constant” will both turn up an incredible variety of articles, papers, discussions, books and viewpoints that all affirm the constant nature of change and the need to embrace it.

Nevertheless, it is sometimes difficult to accomodate change when we also have a legitimate and deep desire to know what is coming next.

For many teams, the environment in which they work is constantly changing. This change can be caused by competition between organizations, scientific or technological advances, fads and cultural shifts, major events in people’s personal lives or even just a change of opinion with a stakeholder. Any change, even small change, can invalidate a planned course of action. However, goals (as distinct from plans) are more stable and often survive even major environmental changes. Therefore, rather than trying to plan the future, an agile team can focus on being able to respond to change while still reaching a goal.

Nevertheless, a team needs some sense of what it will do in the near future. A team can work with a “horizon of predictability”. This is the distance into the future which a team can be reasonably certain that plans will be stable. Depending on the environment, this may be as little as a few minutes, or as long as a month. It is rarely longer. The horizon of predictability is not a precise demarcation, rather, expect change with a probability based on the horizon of predictability. Then, plan to respond to change. Be detached from the concrete details of a plan, particularly if they occur outside the horizon of predictability.

Agile Work - Horizon of Predictability

Responding to change requires a major mental shift for many people that is difficult and takes time and environmental support. People are often penalized socially or formally for being flexible or adaptable. This quality can appear to be “wishy-washy”, uncertain, indecisive, uncommitted or even rebellious.

The terms “agility” or “agile work” refer to this principle of embracing constant change since it is the most visible of the principles. However, the ability to respond to change relies on the establishment of agile work disciplines and practices.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Berteig
Upcoming Courses
View Full Course Schedule
Team Kanban Practitioner® (TKP)
Toronto
C$1095.00
Jan 18
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1695.00
Jan 22
2019
Details
Kanban System Design® (KMP I)
Toronto
C$1695.00
Jan 24
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1395.00
Jan 30
2019
Details
Leading SAFe® with SA Certification (+FREE Scaling Workshop)
Toronto
C$1395.00
Feb 5
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1695.00
Feb 12
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1185.75
Feb 19
2019
Details
Team Kanban Practitioner® (TKP)
Toronto
C$1095.00
Feb 20
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1185.75
Mar 12
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1440.75
Mar 14
2019
Details
PMI Agile Certified Practitioner® (PMI-ACP) with PMI SWOC
London
C$1795.00
Mar 23
2019
Details
Team Kanban Practitioner® (TKP)
Toronto
C$930.75
Mar 25
2019
Details
Kanban System Design® (KMP I)
Toronto
C$1440.75
Mar 26
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1395.00
Mar 26
2019
Details
Kanban Management Professional® (KMP II)
Toronto
C$1355.75
Mar 28
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1440.75
Apr 2
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1395.00
Apr 9
2019
Details
Leading SAFe® with SA Certification (+FREE Scaling Workshop)
Toronto
C$1185.75
Apr 16
2019
Details
Team Kanban Practitioner® (TKP)
Toronto
C$930.75
Apr 17
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1395.00
Apr 24
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1695.00
May 7
2019
Details
Team Kanban Practitioner® (TKP)
Toronto
C$930.75
May 8
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1185.75
May 14
2019
Details
Kanban System Design® (KMP I)
Toronto
C$1440.75
May 15
2019
Details
Certified Agile Leadership® (CAL 1)
Toronto
C$2200.00
Jun 10
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1695.00
Jun 11
2019
Details
Leading SAFe® with SA Certification (+FREE Scaling Workshop)
Toronto
C$1185.75
Jun 18
2019
Details
Team Kanban Practitioner® (TKP)
Toronto
C$1095.00
Jun 19
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1395.00
Jun 20
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1395.00
Jul 4
2019
Details
Kanban System Design® (KMP I)
Toronto
C$1440.75
Jul 4
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1440.75
Jul 11
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1395.00
Jul 16
2019
Details
Team Kanban Practitioner® (TKP)
Toronto
C$1095.00
Jul 31
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1395.00
Jul 31
2019
Details
Kanban Management Professional® (KMP II)
Toronto
C$1355.75
Aug 1
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1695.00
Aug 13
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1395.00
Aug 21
2019
Details
Team Kanban Practitioner® (TKP)
Toronto
C$930.75
Aug 28
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1395.00
Sep 11
2019
Details
Leading SAFe® with SA Certification (+FREE Scaling Workshop)
Toronto
C$1185.75
Sep 17
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1695.00
Sep 17
2019
Details