Scrum Alliance Added Qualifications – Scaling Scrum

The Scrum Alliance just announced through a press release the Added Qualifications [PDF] program.  From the release:

The Added Qualifications program will begin by first offering courses in Scaling Scrum Fundamentals. Those interested in earning an Added Qualification in Scaling Scrum Fundamentals will need to hold at least one of two foundational certifications, Certified ScrumMaster® or Certified Scrum Product Owner®.

More information can be found on the Scrum Alliance Added Qualifications page.

Through World Mindware, we will be introducing courses over the next months to help you achieve these new Added Qualifications.


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Definition of DevOps and the Definition of “Done” – Quick Links

I was poling around for a good definition of DevOps and found a thoughtful article written by Ernest Mueller called What is DevOps?  Highly recommended reading as it includes lots of insight about the relationship between Agile and DevOps.  FWIW, I feel that the concept of the Definition of “Done” is Scrum’s own original take on the same class of ideas: breaking down silos in an organization to get stuff into the marketplace faster and faster.  I even talked about operationalizing software development back in 2004 and 2005 as a counterpoint to the project management approach which puts everyone in silos and pushes work through phase gates.


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Retrospective Technique: What Did You Learn?

Retrospectives are a key part of continuous improvement in Agile teams.  The retrospective techniques that a team uses should be adjusted to the needs of the team.  In a Scrum team, for example, the ScrumMaster will often decide on the techniques to use based on the current issues facing the team and then facilitate the retrospective for the team.  There are some great resources which give you collections of tried-and-true retrospective techniques including Esther Derby’s book “Agile Retrospectives” and the amazing online tool “Retr-o-mat“.  As an active consultant and trainer, I am always looking for new techniques to share with my clients.  Sometimes, I even create a new one (or at least new to me).  The “What Did You Learn” technique is new: I’ve been using it and testing it for a few years now to refine it.

What Did You Learn?

By itself, this is a powerful question.  As part of my work with OpenAgile, I’ve been helping teams and organization to focus on learning as an even broader category than continuous improvement.  The Learning Circle and the processes in OpenAgile help with focusing on learning.  The question “what did you learn?” is very open ended, and can certainly work as an extremely simple type of retrospective in OpenAgile or in Scrum or other Agile methods.  Often people like to have a little more structure and guidance so the “What Did You Learn?” retrospective technique provides four categories of learning for people to think about, share, and discuss within a team.

Setup

Setup for this retrospective is very simple: a flip chart or whiteboard divided into four sections or columns works fine, along with a piece of paper for each person in the retrospective, divided up the same way, and sufficient markers and pens for everyone.  Here is a downloadable PDF version of the handout for the “What Did You Learn” retrospective.

The facilitator will also participate at various points if they are a member of the team (e.g. a ScrumMaster).  It is easiest to do this with a group in-person, but can also be done reasonably well with video or teleconferencing.

Process

The facilitator introduces the retrospective with a welcome and, if necessary, a recitation of the Retrospective Prime Directive.  Then, the process is described to the group.  Each of the categories of learning is also explained as follows:

  • Questions.  When you can formulate a question about something, it means that you have learned about a gap in your knowledge.  In other words, you have discovered something that you would like to learn.
  • Information / Data / Facts.  These are specific details that relate to some area of knowledge or skill.  This category of learning is the simplest and is often what people focus on when asked “what did you learn?”  Information tends to be dry and unemotional.
  • Insights / Concepts / “Aha!” Moments.  Often when we have a collection of facts or an experience, we see a pattern or make interesting connections between things.  This leads us to the great feeling of an insight.  Insights tend to be exciting or scary and have an emotional component.
  • Action Items.  These are decisions about what we would like to do in the future, but they could be extremely short-term or very long-term or anything in between.

There are three main stages in the retrospective as follows:

  1. Individual Reflection.  For 10 to 15 minutes, each individual works silently to write down the things that they have learned in the appropriate category on the handout.  Everyone should try to get at least a couple things into each of the four categories, but more is welcome.
  2. Sharing with the Group.  Systematically going around the group and getting people to read from what they have written.  This is another 10 to 15 minutes.  This stage should not get bogged down in discussion, but brief clarifying questions should be welcome.
  3. Identifying Important Learning.  The group now has open discussion to decide on a small number of things it considers the most important that it has learned.  This could be based on popularity, but impact, depth, or uniqueness might also be factors in considering importance.  These are the items that get written down on the flip-chart.  This is usually the longest part of the retrospective and can take up to 30 minutes.

Applicability

This is an excellent retrospective for a team that is going through a significant transition such as starting a new project, a major change in business direction for a product, or as a wrap up technique for sharing lessons learned with other parts of an organization.  It is not a good technique for a brand new team that hasn’t worked together before as there will be little common ground for deciding on the importance of peoples’ various shared learning.


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

What’s in a Voice? Communicating Who You Are [Updated with edits]

In our professional lives and in doing business, we commonly follow the advice to “dress for success.” We make certain to wear that business suit, or a particular pair of snazzy heels, or a certain color of tie. For better or for worse, we can be judged in the first few seconds of contact with a potential employer or customer by our attire, our hairstyle, our facial expression, our nose ring…

A more subtle way we evaluate a person is through the sound of his or her voice. The voice is a very personal instrument, and it can communicate so much about who you are, your abilities and your intentions.

The voice can tell you whether someone is nervous or at ease. Whether they’re authentic or stringing you a line. Whether they care if they communicate with you or not. When I was a kid, I thought I could detect when someone was lying to me by a certain glitch in the voice, or a tell-tale tone. Often, our brain makes intuitive judgements about what’s being said to us, and is sensitive to vocal rhythm, clarity, tones, and the use of language.

One may think it’s not fair to judge someone by their voice. Let’s face it, a voice – like being short, or having a large nose – is usually unchangeable. But it’s how the voice is used that matters. We all have an inherently full, expressive voice, but things happen to us in life that can negatively influence and/ or harm that voice.

Think of the person who speaks so quietly it’s almost a whisper – you must lean closer to catch what she says. This person may have had some trauma in her life, like being constantly told as a child to ‘be quiet’, to de-voice her. I know people whose greatest fear is public speaking, who quake inwardly and outwardly, even if they have something important to share with others.

Personality is also expressed through the voice. Imagine the annoyingly loud talker sitting nearby in a restaurant. This is certainly someone who wants too much attention and tries to get it by being overbearing. Or the fast-talker, who doesn’t want any other opinions but his own to be expressed, and doesn’t give the listener an opportunity to think or to respond, lest they disagree with him.

Anyone can be trained to use their voice for positive communication. A voice is an instrument that can become effective and optimal with practice.

Here’s a few things to think about in how you use your voice:

  • Are you clearly enunciating your words so as not to be mis-heard?

  • Are you directing your voice to the person or people you want to communicate with?

  • Are you speaking in a rhythm that’s neither too fast nor too slow?

  • Are you allowing your true feelings or intentions to come through?

  • Are you being honest?

The voice is just one of the important tools we use to communicate. If your work requires relating to other people in any way, for example, making presentations, or promoting a product, consider how you use your voice and what it may communicate about you!


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Agile Manifesto – Essay 2: Individuals and Interactions over Processes and Tools

This value is the hardest to do well.

In IT and high-tech, there is a “natural” prevailing culture that makes this first value incredibly difficult.  This difficulty is rooted in traditional “scientific management“, but made even more so by a critical additional factor that is mostly invisible: techies solve problems with tools.

Management wants to define processes with clearly described activities, clear inputs and outputs, and clear sources and recipients of the activity (see the description of SIPOC for an explanation of this thinking).  Techies build tools to automate these well-defined processes to improve their efficiency, quality and reliability.

Management creates organizational roles with detailed descriptions, detailed goals and detailed performance measurements (see the description of RACI for an explanation of this thinking).  Techies build tools to carefully constrain people to these detailed roles to improve efficiency, quality and reliability.

Management has money.  Techies want some of that money.  So they build the tools to help management get what they really want: a completely automated organization of computers, machines and robots.

The culture of technology is to solve problems with individuals and interactions by introducing processes and tools.  The culture of technology is (almost) inherently anti-Agile.

Ford Assembly Line 1913

The culture of technology is to solve problems with individuals and interactions by introducing processes and tools.  The culture of technology is (almost) inherently anti-Agile.


 

BMW Assembly Line

Individuals and Interactions

Let’s look at the first part of this value in a bit more depth.  When we think about work, most of us work with other people.  We bring our unique skills, personality and interests to work, and we work with other people who also bring unique skills, personality and interests.  In a high-bureaucracy, high-technology work environment, it is easy to forget about all this uniqueness and instead objectify people.  When people sense they are being objectified, mostly they feel bad about it.  We want to be acknowledged as thinking, feeling, unique beings with agency.  Objectification, no matter the source or the rationale, is depressing and de-humanizing.  The Agile Manifesto implicitly recognizes this concept and asks us who follow the Manifesto to try to shift our value-focus.

There are many aspects to this concept of humanizing work.  Some things that come to mind immediately include recognizing and encouraging people’s capacity for:

  • creativity and innovation
  • learning and problem-solving
  • caring about others
  • pride in work
  • complementarity with others
  • responsibility

Photo of diverse children teamwork

Processes and Tools

This side of the value is also interesting.  Processes and tools do not have agency.  They do not improve on their own.  Instead, processes and tools only either remain the same or degrade.  Processes and tools are forces for stasis: they encourage maintenance of the status quo.  Only humans introduce new processes and tools.

Technologists live in a philosophical double-standard: we build processes and tools for others to use and which we frequently would not like used on ourselves.  (We will discuss the cases where me might both build and benefit from processes and tools in a bit.)  This is one of the challenges of the type of work we do in technology, but it also applies to many other types of work.  So how do we solve this conundrum?  I would assert that the principles of the Agile Manifesto and the various Agile methods and techniques are all answers to this question.  They show us possible ways to implement this value (and the others) without getting stuck in processes and tools.

Only humans introduce new processes and tools.


 

What are Processes Good For, What are Tools Good For?

Some processes are good.  Some amount of process is good.  How do we determine what is good?  Well, it largely depends on context.  Some examples:

If a close family member is living in a distant location then the advances in communication tools are extremely helpful: the telegraph, the telephone, the cell phone, email, Skype.  These tools create connections where otherwise there would be little or none.

If a great deal of data is created while running a marketing campaign and needs to be stored and manipulated, then computers are amazing tools for this.  Computers are much much better than human minds and manual record-keeping for this sort of work.

If you create a fantastic new soup, from scratch, for some special occasion and you want to remember how to make and even share how to make it with others, then you document the process in a recipe.

Photo of Pho Soup

Context, Emphasis and Crisis

Context here is important.  The value of Individuals and Interactions over Processes and Tools is basically a statement that given the right circumstances we can use processes and tools, but that our default approach to work and problem-solving should be to focus on individuals and their interactions.  Depending on the state of your work environment this is easier or harder.

For example, a startup company founded by three long-time friends who have not yet employed anyone else is almost certainly going to solve most problems that come up through discussion amongst founders and through the development of their skills and capabilities.  As a company gets larger, however, there is pressure to adopt more and more processes and tools.  This pressure comes from a deep source: lack of trust.  At about 12 people, you reach the limit of the number of people you can have and still have anyone do anything (this limit is referred to obliquely in “The Wisdom of Teams” by Katzenbach and Smith).  After 12 people, it becomes harder to avoid role specialization and some basic forms of processes and tools.  In other words, bureaucracy starts growing as the organization grows.  Even at this size, however, it is still relatively easy to have a very strong emphasis on individuals and interactions.  There is another important limit: somewhere around 150 to 200 people, any hope of 100% mutual trust among the members of the organization is lost.  This is the point at which processes and tools “naturally” start to truly take over.  (This transition can happen even in much smaller organizations if the culture does not emphasize trust-based interactions.)

In small trust-based organizations, crisis is usually addressed by the mechanisms of mutual respect, skill development, informal agreements, and strengthening the interactions between people.  In a large organization with low trust, crisis is almost always addressed by the creation of new bureaucracy: sign-offs, audits, traceability, procedures, policies, processes and tools.

The true test of the an organization’s commitment to the first value of the Agile Manifesto is, therefore, how it responds to crisis.  When someone makes a mistake, can we help them develop the skill and the support networks to avoid the mistake in the future?  Or do we put in place even more restrictive constraints on what that person does and how they do it?

In a large organization with low trust, crisis is almost always addressed by the creation of new bureaucracy.


 

Beyond IT and High-Tech

For now, all that needs to be said is that this particular value of the Agile Manifesto does not in any way directly refer to software or software development.  As such, it is pretty easy to see how it could be applied in many other types of work.  However, there are some types of work where processes and tools really do take precedence over individuals and interactions.  If we want to apply the concepts of Agile universally (or near-universally), we have to examine some of these exceptions.  I will leave that for a future essay.

In the next few articles, I will continue to look in-depth at each of the values of the Agile Manifesto.  If you missed the first essay in this series, please check it out here: The Agile Manifesto – Essay 1: Value and Values.


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Agile Manifesto – Essay 1: Value and Values

What is Agile?

In 2001, 17 people got together for a world-changing discussion about software development. They tried to find the common values and principles by which people could do better at the work of software development, which was in a terrible crisis (and still, to some extent is). They were successful in that they created a list of 4 values and 12 principles to guide people trying to find better ways of developing software: the Agile Manifesto was born.

Now, nearly 14 years later, Agile software development has become well-known (if not well-practiced) throughout the business world. In fact, the concepts of Agile software development have been extended through to many other fields as diverse as mining, church management, personal time management, and general corporate management. In the process, there has also been a growing recognition of the relationship between Agile values and principles and those of Lean thinking.

It is time to think about the concepts behind the values and principles. To acknowledge that the Agile Manifesto (for software development) can be re-stated at a much deeper level. To abstract Agile software development to Agile work in general. This is my goal over a series of essays about the Agile Manifesto.

Let’s start with an analysis of the values of the Agile Manifesto in relationship to the concept of “value”.

The Agile Manifesto Values

In the Agile Manifesto we can read the four values:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

While a few of these already are quite general, let’s dig a bit deeper by starting with the second value, “working software over comprehensive documentation”. What does this value really refer to? Why do we care about software over documentation. Why “working” vs. “comprehensive”? This is where Lean thinking can help us. The notion of “customer value-added” or just value added work is any work that changes the form, fit or function of that which you are delivering and simultaneously is work that a customer would pay for independently of all the other activities and results you may be spending time on. In this specific example of software and documentation, we can try to imagine what it would be like to say to a potential customer, “we can give you documentation for our software, but we won’t be able to give you the actual software itself… but we’d still like to be paid.” I’m sure it will be clear that it would be a very unusual customer who would agree to such a proposal. Thus, we see that the value of software development activities is in producing the software itself, and the documentation is by necessity of secondary importance.

But what if we are writing a book of fiction? Surely this is documentation! But, it is not. To make the analogy to the type of documentation mentioned in the Agile Manifesto, we would sell a book not just with the story itself, but also with in-depth instructions on how to use a book, how to read, how to interpret our feelings as we read, etc. And not just that, but we would also provide a set of notes to the publisher about exactly how we wrote the book: the time and place of each paragraph written, our original outlines, our research including much that was thrown away, all our conversations with people as we struggled to sort out various plot, character and setting elements, and possibly even all our edits that we had thrown away. This is the documentation to which, by analogy, the Agile Manifesto is referring.

Perhaps now we can look at a connection between the first value and the second value of the Manifesto: that documentation, tools and processes are all much of the same thing. They all belong to the same abstract category, namely, the means used to achieve a particular end. Of course, we all know that both the means and the ends are important, although we may not all agree on their relative importance. Nevertheless, we can probably agree on some extreme outliers that will help us come to the point I wish to make. For example, we can agree that killing someone merely to get to the front of the grocery store line and save a minute or two of time is an extreme case where the end clearly does not justify the means. Likewise, we can also agree that refusing honestly given help out of a desire for independence when it ends with the death of our children by starvation is putting means too much in the fore. Balance is required, therefore. The Agile Manifesto acknowledges this balance by its epilogue to the values, “That is, while there is value in the items on the right, we value the items on the left more.” The other two values of the Agile Manifesto which mention contract negotiation and following a plan are similarly pointing out activities of the means that are non-value added, in Lean terms.

The Agile Manifesto, is stating four values, is, quite directly, pointing to those things which in life are fundamentally of value as ends, not just as means. Individuals and interactions, working software, customer collaboration and responding to change, are all valuable. In order to abstract away from software, then, and create a more general statement of the nature of Agility, we need to explore the idea of value.

The Idea of Value

If we are in business, determining value, while possibly complicated, is not usually too obscure an effort. We look at exchanges of money to see where the “market” agrees there is value. The price of a product or service is only representative of value if someone will actually pay. Therefore, businesses look at return on investment, profit margins and the like to determine value. Similarly, in other types of markets such as the stock market, value is determined by an exchange of money. But underlying this exchange of money is a decision made by an individual human being (or several, or many) to refuse all the other potential uses of that money for the one specific use of making a particular purchase. This choice is based on all sorts of factors. In economics, we talk about these factors mostly in rational selfish terms: what sort of benefit does the purchaser get from the purchase. Factors such as risk, short-term vs. long-term, net present value, trade-offs, etc. certainly can play a role in such decisions. But in business (and in particular marketing and sales), we know that there are also lots of non-rational forces at work in deciding to spend money on a particular something. Value, therefore, has a great deal to do with how a particular person both feels and understands the current proposed “investment” opportunity.

Feeling and understanding arise from many specific factors, as discussed, but what can we say generally about feeling and understanding? They are internal states of a person’s mind (or heart, if you like). Those internal states have been the subject of much discussion in the realm of psychology, sociology, economics, and philosophy. But quite simply, those internal states are greatly determined by perception. How a person perceives a situation is the immediate general factor that determines those internal states. Of course, perception is a general term that includes sensory perception, but also the kinds of prejudices we have, the categories into which we place things conceptually, the internal language we use to describe things, and our existing emotional and mental constructs. So, fundamentally, value is perceived depending on all these perceptual factors.

The Agile Manifesto authors, therefore, had (and perhaps still have) a perception of value which places individuals and interactions, working software, customer collaboration and responding to change all in a position of more value than those other items. But this perception of value may not be in alignment with other people’s perception of value. Still, we can see already in 13 short years that there is broad, if not universal, agreement on these statements of value. Why is this? Why has Agile become so popular over a relatively sustained length of time with a trajectory that still seems to have it growing in popularity for years to come?

Agile values address a deep need in people in the software development discipline and indeed, by analogy, into much of the work world.

In my next essay on the Agile Manifesto, we will take a look in more depth at the first value of the Agile Manifesto: Individuals and Interactions over Processes and Tools.

Some links to commentary on the values of the Agile Manifesto while you wait for my next essay instalment!…

Individuals and interactions over processes and tools – by Mark Layton

Working software over comprehensive documentation – by Renee Troughton

Customer collaboration over contract negotiation – by Jared Richardson

Responding to change over following a plan – by Chris Matts


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcing the Agile Advice eBook – Finally Ready!

Agile Advice Book - coverThanks everyone for feedback, comments and suggestions for my new book, Agile Advice – Creating High Performance Teams In Business Organizations.  It is available for purchase (only $2.99) on lulu.com (that’s where the link goes).  Here is the blurb about the book:

Agile Advice is a collection of brief articles and longer essays about Agile methods and their principles and practices. Agile Advice articles come primarily from the popular AgileAdvice.com blog which has been in the top 50 of Agile blogs since its inception in 2005. The book has three never-before-seen essays including “Agile Mining at a Large Canadian Oil Sands Company”, “Crossing the Knowing-Doing Gap”, and “Becoming a Professional Software Developer”. Agile Advice also has a whole section on choosing an Agile method. The author, Mishkin Berteig, has been working with Agile methods such as Scrum, Kanban, and Extreme Programming since 1996.

Once you have read it, I would love to hear your feedback and reviews here.  I will try to publish updates quarterly over the next year to make it even better!  Thanks again for your support.


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Family Kanban for Cleaning

Two nights ago I had a great discussion with my son, Justice Berteig, about how we have been managing to do house cleaning every week.  We have been using a very basic Kanban system.  I have created about 100 stickies each of which has a basic cleaning task such as “tidy the kitchen counters” or “vacuum the office floor” or “clean the powder room toilet”.  If we do all of the tasks, it represents a fairly complete cleaning of the whole house.  Every Saturday morning, all six of us (myself, my wife and our four kids) choose one task at a time and put the sticky for that task in the “In Progress” column.  When we finish a task, we move it to the “Done” column.  When all the tasks are done, we all are finished.  We reuse the stickies each week.  Sometimes if we want to do a quick clean, we won’t put out all of the stickies.Cleaning Kanban - Task

It works well in one specific way: everything gets done!

But Justice was complaining about the system because he works a lot harder and one of my younger kids has admitted to doing less than she could… because she can get away with it with this system.

Last week we tried a modified system where each person has a task allocation.  For example, Justice had an allocation of 25 tasks.  Our younger daughter had an allocation of just 5 tasks.  We then took turns to choose one task at a time (although there were a lot of exceptions to this) until all the tasks are pre-allocated (similar to how teams used to do Sprint Planning).  But, although some people finished all their tasks, not everyone did and so there were a number of things left over that never got finished.

In other words, we stopped using a Kanban system, and we stopped reaching the overall goal of a clean house.

So Justice and I had a long conversation about this problem.  In the interests of continuous improvement and experimentation, I didn’t just force the issue back to the old Kanban system.  Instead we decided to try the following changes:

  1. Limit the tasks to only those in common areas.  Private areas such as bedrooms would be taken off the master list.
  2. Each task would get an estimate from a scale of 1 to 3 to represent their relative difficulty.  We will talk as a family about the estimates and maybe use a simplified “bucket system“.
  3. Now, instead of an allocation of a specific number of tasks, the allocation would be for a total amount of effort.  We agreed that our youngest would get a smaller allocation still, but she could take any number of tasks to fill it up.
  4. We also agreed to be more disciplined about taking turns to choose tasks.

I’m going to add one more thing which is to do a specific retrospective on how it worked to see if we can come up with further improvements.  I have to admit that I hope we go back to the Kanban approach!!!

Check out our new Kanban training offering: Kanban: Gentle Change currently available for public enrolment in the Toronto area and for in-house delivery wherever you might be!


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcing: The Real Agility Program

Real Agility Program LogoThe Real Agility Program is an Enterprise Agile change program to help organizations develop high-performance teams, deliver amazing products, dramatically improve time to market and quality, and create work environments that are awesome for employees.

This article is a written summary of the Executive Briefing presentation available upon request from the Real Agility Program web site.  If you obtain the executive briefing, you can follow along with the article below and use it to present Real Agility to your enterprise stakeholders.

The Problem

At Berteig Consulting we have been working for 10 years to learn how to help organizations transform people, process and culture.  The problem is simple to state: there is a huge amount of opportunity waste and process waste in most normal enterprise-scale organizations.  If you have more than a couple hundred people in your organization, this almost certainly affects you.

We like to call this problem “the Bureaucratic Beast”.  The Bureaucratic Beast is a self-serving monster that seems to grow and grow and grow.  As it grows, this Beast makes it progressively more difficult for business leaders to innovate, respond to changes in the market, satisfy existing customers, and retain great employees.

Real Agility, a system to tame the Bureaucratic Beast, comes from our experience working with numerous enterprise Agile adoptions.  This experience, in turn, rests on the shoulders of giants like John Kotter (“Leading Change”), Edgar Schein (“The Corporate Culture Survival Guide”), Jim Collins (“Good to Great” and “Built to Last”), Mary Poppendieck (“Lean Software Development”) Jon Katzenbach (“The Wisdom of Teams”) and Frederick Brooks (“The Mythical Man-Month”).  Real Agility is designed to tame all the behaviours of the Bureaucratic Beast: inefficiency, dis-engaged staff, poor quality and slow time-to-market.

Studies have proven that Agile methods work in IT.  In 2012, the Standish Group observed that 42% of Agile projects succeed vs. just 14% of projects done with traditional “Bureaucratic Beast” methods.  Agile and associated techniques aren’t just for IT.  There is growing use of these same techniques in non-technoogy environments such as marketing, operations, sales, education, healthcare, and even heavy industry like mining.

Real Agility Basics: Agile + Lean

Real Agility is a combination of Agile and Lean; both systems used harmoniously throughout an enterprise.  Real Agility affects delivery processes by taking long-term goals and dividing them into short cycles of work that deliver valuable results rapidly while providing fast feedback on scope, quality and most importantly value.  Real Agility affects management processes by finding and eliminating wasteful activities with a system view.  And Real Agility affects human resources (people!) by creating “Delivery Teams” which have clear goals, are composed of multi-skilled people who self-organize, and are stable in membership over long periods of time.

There are lots of radical differences between Real Agility and traditional management (that led to the Bureaucratic Beast in the first place).  Real Agility prioritizes work by value instead of critical path, encourages self-organizing instead of command-and-control management, a team focus instead of project focus, evolving requirements instead of frozen requirements, skills-based interactions instead of roles-based interaction, continuous learning instead of crisis management, and many others.

Real Agility is built on a rich Agile and Lean ecosystem of values, principles and tools.  Examples include the Agile Manifesto, the “Stop the Line” practice, various retrospective techniques, methods and frameworks such as Scrum and OpenAgile, and various thinking tools compatible with the Agile – Lean ecosystem such as those developed by Edward de Bono (“Lateral Thinking”) and Genrich Altshuller (“TRIZ”).

Real Agility acknowledges that there are various approaches to Agile adoption at the enterprise level: Ad Hoc (not usually successful – Nortel tried this), Grassroots (e.g. Yahoo!), Pragmatic (SAFe and DAD fall into this category), Transformative (the best balance of speed of change and risk reduction – this is where the Real Agility Program falls), and Big-Bang (only used in situations of true desperation).

Why Choose Transformative?

One way to think about these five approaches to Agile adoption is to compare the magnitude of actual business results.  This is certainly the all-important bottom line.  But most businesses also consider risk (or certainty of results).  Ad-Hoc approaches to Agile adoption have poor business results and a very high level of risk.  Big-Bang approaches (changing a whole enterprise to Agile literally over night) often have truly stunning business results, but are also extremely high risk.  Grassroots, where leaders give staff a great deal of choice about how and when to adopt Agile, is a bit better in that the risk is lower, but the business results often take quite a while to manifest themselves.  Pragmatic approaches tend to be very low risk because they often accommodate the Bureaucratic Beast, but that also limits their business results to merely “good” and not great.  Transformative approaches which systematically address organizational culture are just a bit riskier than Pragmatic approaches, but the business results are generally outstanding.

More specifically, Pragmatic approaches such as SAFe (Scaled Agile Framework) are popular because they are designed to fit in with existing middle management structures (where the Bureaucratic Beast is most often found).  As a result, there is slow incremental change that typically has to be driven top-down from leadership.  Initial results are good, but modest.  And the long term?  These techniques haven’t been around long enough to know, but in theory it will take a long time to get to full organizational Agility.  Bottom line is that Pragmatic approaches are low risk but the results are modest.

Transformative approaches such as the Real Agility Program (there are others too) are less popular because there is significantly more disruption: the Bureaucratic Beast has to be completely tamed to serve a new master: business leadership!  Transformative approaches require top-to-bottom organizational and structural change.  They include a change in power relationships to allow for grassroots-driven change that is empowered by servant leaders.  Transformative approaches are moderate in some ways: they are systematic and they don’t require all change to be done overnight. Nevertheless, often great business results are obtained relatively quickly.  There is a moderate risk that the change won’t deliver the great results, but that moderate risk is usually worth taking.

Regardless of adoption strategy (Transformative or otherwise) there are a few critical success factors.  Truthfulness is the foundation because without it, it is impossible to see the whole picture including organizational culture.  And love is the strongest driver of change because cultural and behavioural change requires emotional commitment on the part of everyone.

Culture change is often challenging.  There are unexpected problems.  Two steps forward are often followed by one step back.  Some roadblocks to culture change will be surprisingly persistent.  Leaders need patience and persistence… and a systematic change program.

The Real Agility Program

The Real Agility Program has four tracks or lines of action (links take you to the Real Agility Program web site):

  1. Recommendations: consultants assess an organization and create a playbook that customizes the other tracks of the Real Agility Program as well as dealing with any important outliers.
  2. Execution: coaches help to launch project, product and operational Delivery Teams and Delivery Groups that learn the techniques of grassroots-driven continuous improvement.
  3. Accompaniment: trainer/coaches help you develop key staff into in-house Real Agility Coaches that learn to manage Delivery Groups for sustainable long-term efforts such as a product or line of business.
  4. Leadership: coaches help your executive team to drive strategic change for long-term results with an approach that helps executives lead by example for enterprise culture change.

Structurally an enterprise using Real Agility is organized into Delivery Groups.  A Delivery Group is composed of one or more Delivery Teams (up to 150 people) who work together to produce business results.  Key roles include a Business leader, a People leader and a Technology leader all of whom become Real Agility Coaches and take the place of traditional functional management.  As well, coordination across multiple Delivery Teams within a Delivery Group is done using an organized list of “Value Drivers” maintained by the Business leader and a supporting Business Leadership Group. Cross-team support is handled by a People and Technology Support Group co-led by the People and Technology leaders.  Depending on need there may also be a number of communities of practice for Delivery Team members to help spread learning.

At an organizational or enterprise level, the Leadership Team includes top executives from business, finance, technology, HR, operations and any other critical parts of the organization.  This Leadership Team communicates the importance of the changes that the Delivery Groups are going through.  They lead by example using techniques from Real Agility to execute organizational changes.  And, of course, they manage the accountability of the various Delivery Groups throughout the enterprise.

The results of using the Real Agility Program are usually exceptional.  Typical results include:

  • 20x improvement in quality
  • 10x improvement in speed to market
  • 5x improvement in process efficiency
  • and 60% improvement in employee retention.

Of course, these results depend on baseline measures and that key risk factors are properly managed by the Leadership Team.

Your Organization

Not every organization needs (or is ready for) the Real Agility Program.  Your organization is likely a good candidate if three or more of the following problems are true for your organization:

  • high operating costs
  • late project deliveries
  • poor quality in products or services
  • low stakeholder satisfaction
  • managers overworked
  • organizational mis-alignment
  • slow time-to-market
  • low staff morale
  • excessive overtime
    or…
  • you need to tame the Bureaucratic Beast

Consider that list carefully and if you feel like you have enough of the above problems, please contact us at tame.the.beast@berteigconsulting.com. or read more about the Real Agility Program for Enterprise Agility on the website.


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcing New Agile Training for Coaches, Executives, Job Seekers and More

New Agile Certification Training

Certified Real Agility Coach LogoOur new premium offering: the Certified Real Agility Coach course is delivered in an unusual format of 40 days (yes, forty) spread over one year.  This in-depth, advanced training program is designed to help people with experience on Agile teams to become fully-capable independent Agile coaches.  Worried about the time commitment?  A substantial portion of the course is delivered as on-the-job training and a significant number of course hours are outside regular working hours… and the schedule is flexible to accommodate participants’ unique scheduling needs.  Spots are extremely limited for this course.  Reserve your spot now! (Contributes all the training hours required for the Certified Scrum Professional designation.  As well, if you do not already have the CSM and CSPO designations, you will receive free enrolment in either or both of those courses once your registration has been confirmed.)

Scaled Agile Framework - SAFe Agiilist LogoSince Travis Birch and Mishkin Berteig have become Certified SAFE Program Consultants, we are now offering the Leading Safe 2-day course for project, program and functional managers, change agents and department leaders.  Learn about the Scaled Agile Framework; one the most popular enterprise Agile frameworks.  SAFe combines Scrum, Extreme Programming and Lean to effectively allow larger groups of people to execute programs while interfacing effectively with traditional corporate governance.  Do you have 25 people or more working on a program?  Then the Leading SAFe training is for you!

New Agile Introduction Courses

Scrum and Enterprise Agile for Executives is a half-day workshop designed to help you solve one of the biggest problems organizations have: how to become more Agile?  Using the tools and techniques of the Real Agility Program, participants will be guided to make effective long- and short-term plans for increasing productivity, innovation, quality and customer satisfaction.  This workshop is delivered by Mishkin Berteig who has helped numerous executives at organizations large and small with successful Agile transformations.  Just $250 per person!

Travis Birch, a Partner at Berteig Consulting who has years of experience helping Agile teams reach award-winning levels of performance, is going to be delivering two of our new offerings:

Choosing an Agile Career is a one-day workshop designed to help people who don’t yet know how they can best fit into the most important revolution sweeping the corporate world.  Should you be a ScrumMaster?  A Product Owner?  An Agile Coach?  Something else?  Ideal for people who have been asked by their executives to sort out their career path in a newly Agile organization or department.  $450/person with an early-bird discount available for some dates.

Kanban: Gentle Change is a deep-dive immersion into a critical process-improvement and teamwork technique  Learn how tools for making work visible can improve productivity, throughput and efficiency..  Ideally suited for team leads, project and functional managers, HR managers and process improvement managers.  $450/person with an early-bird discount available for some dates.  Counts as 7 PDUs with the PMI and contributes to the Agile Certified Practitioner designation.

Other Workshops

CSM Certified ScrumMaster LogoCSPO Certified Scrum Product Owner Logo

Of course, we continue to offer our extremely well-received (often sold out!) Certified ScrumMaster and Certified Scrum Product Owner training courses.  These courses are immersive, intensive, and designed to help you to become great ScrumMasters and Product Owners.

Please see our complete 2015 Agile and Scrum course schedule here!  Most of our courses are held in the Toronto area which has a great international airport, fantastic food, amazing entertainment, and is just generally a fun place to come for a bit of training and a bit of sight-seeing.  Some courses are also offered in other cities including Vancouver, London Ontario, and Waterloo.  Most of our courses are also available for in-house private dates.  Please contact learn@worldmindware.com for more information about group discounts, corporate savings programs or in-house private offerings.

COMING SOON We are working to offer Certified Scrum Developer (CSD) training as a complement to our already successful Certified ScrumMaster and Certified Scrum Product Owner training courses.  The CSD course will help technology professionals learn the critical Agile engineering and teamwork practices that are absolutely required to make Scrum successful in delivering software products.  This training is highly technical and participants are expected to already be strong software developers.


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Best Agile Advice Articles – Ten Year Anniversary!

Agile Advice was started in 2005.  In ten years, we have published over 850 articles (an average of just about 2 per week!).  Here are some collections of the ten “best” articles.  I hope you enjoy looking back at (or discovering for the first time!) some of the things that have made this such a great joy for me.

Ten Most Popular Agile Advice Articles

  1. How Two Hours Can Waste Two Weeks (75,000+ visits)
  2. The Seven Core Practices of Agile Work (25,000+ visits)
  3. Eight Barriers to Effective Listening (17,000+ visits)
  4. Seven Essential Teamwork Skills (17,000+ visits)
  5. 24 Common Scrum Pitfalls Summarized (15,000+ visits)
  6. Mentoring and Coaching: What is the Difference? (14,000+ visits)
  7. Wideband Delphi Estimation Technique (14,000+ visits)
  8. The Pros and Cons of Short Iterations (13,000+ visits)
  9. Three Concepts of Value Stream Mapping (13,000+ visits)
  10. Agile Work and the PMBoK Definition of Project (11,000+ visits)

Ten Most Commented Upon Agile Advice Articles

  1. 24 Common Scrum Pitfalls Summarized (19 comments)
  2. Agile Becomes Easier with Useful Tools (12 comments)
  3. Important Words about Scrum and Tools (9 comments)
  4. The Skills Matrix and Performance Evaluation on Agile Teams (9 comments)
  5. The Definition of Done is Badly Named (8 comments)
  6. How Two Hours Can Waste Two Weeks (7 comments)
  7. Agile is Not Communism (7 comments)
  8. Agile Tools vs. Agile Books (6 comments)
  9. The Decline and Fall of Agile and How Scrum Makes it Hurt More (5 comments)
  10. The Planning Game: an Estimation Method for Agile Teams (5 comments)

I also want to acknowledge that there are a number of other contributors to Agile Advice besides me (Mishkin).  These contributors are all experts, all have great experiences, and all are fantastic people to know.  I’m grateful for their contributions since they have all made Agile Advice a better place to browse!

Five Most Frequent Contributors (of Articles, besides Mishkin)

  1. Paul Heidema (34 articles)
  2. Travis Birch (24 articles)
  3. Christian Gruber (19 articles)
  4. Mike Caspar (16 articles)
  5. Shabnam Tashakour (13 articles)

Plans for the Future – Five Top Ideas for Series

  1. Essays on each of the Values and Principles of the Agile Manifesto
  2. Summary articles of several Agile methods including Scrum, OpenAgile, Kanban, Crystal, XP, and others
  3. Real Agility Program case studies
  4. Reviews of other scaling / enterprise Agile frameworks such as Disciplined Agile Delivery, Large Scale Scrum, Enterprise Scrum
  5. New guest articles from thought and practice leaders.

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Taking a break for the holiday season

I wish everyone well and I hope you too have a chance to spend time with loved ones, rest, do some annual Kaizen (oops – I mean “new year’s resolutions”), and, if you have the means, reach out and help someone in need!

We’ll be back on Jan 1 with some pre-scheduled content including some exciting announcements that should be great reading as you start heading back in to the work of the new year.


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Comparison of the ScrumMaster, Product Owner, Project Manager and Team Lead Roles

Often in my classes, I’m asked for a clear comparison between the various traditional roles and the new roles in Scrum.  Here is a high level summary of some of the key responsibilities and activities that help highlight some important differences between these four roles:

ScrumMaster Product Owner Project Manager Team Lead
NEVER NEVER Assign Tasks YES
NO PARTICIPATES Create Schedule NO
NO YES Manage Budget NO
Remove Obstacles PARTICIPATES YES YES
NO Define Business Requirements PARTICIPATES NO
NO YES (Deliveries) Define Milestones NO
Facilitate Meetings NO YES YES
YES (process and people) YES (business) Risk Management PARTICIPATES
Organizational Change Agent NO NO NO
NO Accountable for Business Results RARELY (just costs) NO

Of course, there are many other ways we could compare these four roles.  What would you like me to add to this list?  Add a comment with a question or a suggestion and I will update the table appropriately!


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail