Tag Archives: Work

Pitfall of Scrum: Assigning Tasks

Learn more about transforming people, process and culture with the Real Agility Program

Even though the concept of self-organizing teams has been around for a long time, still some people think that a project manager or team lead should be assigning tasks to team members. Don’t do this!!!  It is better to wait for someone to step up than to “take over” and start assigning tasks.

Assigning tasks can be overt or subtle.  Therefore, avoid even suggestions that could be taken as assigning tasks. For example, no one should ever tell a Scrum Team member “hey! You’re not doing any work – go take a task!” (overt) or “This task really needs to get done – why don’t you do it?” (semi-overt) or “Would you consider working on this with me?” (subtle). Instead, any reference to tasks should be to the team at large. For example it would be okay for a team member to say “I’m working on this and I would like some help – would anyone help me?”

In the Scrum Guide, a partial definition of self-organizing is given:

Scrum Teams are self-organizing….. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.

A more formal definition of the concept of “self-organizing” can be found here:

Self-organisation is a process where some form of global order or coordination arises out of the local interactions between the components of an initially disordered system. This process is spontaneous: it is not directed or controlled by any agent or subsystem inside or outside of the system; however, the laws followed by the process and its initial conditions may have been chosen or caused by an agent.

The key here is that there is no single point of authority, even temporarily, in a self-organizing team. Every individual member of the team volunteers for tasks within the framework of “the laws followed by the process” – namely Scrum. Scrum does define some constraints on individual behaviour, particularly for the Product Owner and the ScrumMaster. People in those two roles have specific duties which usually prevent them from being able to volunteer for any task. But all the other team members (the Development Team) have complete freedom to individually and collectively figure out how they will do the work at hand.

What If One Person Isn’t Working?

People who are managers are often worried about this.  What if there is one person on the team who just doesn’t seem to be doing any work? Isn’t assigning tasks to this person a good thing?  Scrum will usually make this bad behaviour really obvious. Let’s say that Alice hasn’t completed any tasks in the last four days (but she does have a task that she volunteered for at the start of the Sprint). Raj notices that Alice hasn’t finished that initial task. An acceptable solution to this problem is for Raj to volunteer to help Alice. Alice can’t refuse the help since Raj is self-organizing too. They might sit together to work on it.

Of course, that might not solve the problem. So another technique to use that respects self-organization is to bring it up in the Sprint Retrospective. The ScrumMaster of the team, Sylvie, chooses a retrospective technique that is designed to help the team address the problem. In a retrospective, it is perfectly acceptable for people on the team to be direct with each other. Retrospectives need to be safe so that this kind of discussion doesn’t lead to animosity between team members.

Remember: everyone goes through ups and downs in productivity. Sometimes a person is overwhelmed by other aspects of life. Sometimes a person is de-motivated temporarily. On the other hand, sometimes people become extremely engaged and deliver exceptional results. Make sure that in your team, you give people a little bit of space for these ups and downs.  Assigning tasks doesn’t make a person more productive.

What If There is One Task No One Wants to Do?

Dig deep and find out why no one wants to do it. This problem is usually because the task itself is worthless, frustrating, repetitive, or imposed from outside without a clear reason. If no one wants to do a task, the first question should always be: what happens if it doesn’t get done? And if the answer is “nothing bad”… then don’t do it!!!

There are, unfortunately, tasks that are important that still are not exciting or pleasant to do. In this situation, it is perfectly acceptable to ask the team “how can we solve this problem creatively?” Often these kinds of tasks can be addressed in new ways that make them more interesting. Maybe your team can automate something. Maybe a team member can learn new skills to address the task. Maybe there is a way to do the task so it never has to be done again. A self-organizing Scrum Team can use innovation, problem-solving and creativity skills to try to over come this type of problem.

And, of course, there’s always the Sprint Retrospective!

Why Self-Organize – Why Is Assigning Tasks Bad?

Autonomy is one of the greatest motivators there is for people doing creative and problem-solving types of work. The ability to choose your own direction instead of being treated like a mushy, weak, unreliable robot. Motivation, in turn, is one of the keys to creating a high-performance state in individuals and teams. The greatest outcome of good self-organization is a high-performance team that delivers great work results and where everyone loves the work environment.

Assigning tasks to people is an implicit claim that you (the assigner) know better than them (the assignees).  Even if this is true, it is still easy for a person to take offence.  However, most of the time it is not true.  People know themselves best.  People are best at assigning tasks to themselves.  And therefore, having one person assigning tasks to other people almost always leads to sub-optimal work distribution among the members of a team.

The ScrumMaster and Assigning Tasks

The ScrumMaster plays an important role in Scrum.  Part of this role is to encourage self-organization on a team.  The ScrumMaster should never be assigning tasks to team members under any circumstances.  And, the ScrumMaster should be protecting the team from anyone else who is assigning tasks.  If someone within the team is assigning tasks to another team member, the ScrumMaster should be intervening.  The ScrumMaster needs to be constantly aware of the activity on his or her team.

I have added a video to YouTube that you might consider sharing with ScrumMasters you know about this topic:

This article is a follow-up article to the 24 Common Scrum Pitfalls written back in 2011.

Please share!

The Agile Manifesto – Essay 1: Value and Values

Learn more about transforming people, process and culture with the Real Agility Program

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!

Foundations of Excellence

Learn more about transforming people, process and culture with the Real Agility Program

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.

Please share!

The Rules of Scrum: Your Product Owner never does hands-on technical work with the team

Learn more about transforming people, process and culture with the Real Agility Program

The Product Owner’s main responsibility is to maintain the Product Backlog through direct communication with the users and stakeholders. To do this well it will take most of his time and effort to be effective. Hands-on technical is done by the Team Members not the Product Owner since this is not the Product Owner’s strength or area of expertise. If the Product Owner refrains from doing the hands-on technical work, then he is able to provide the vision and share the “what” that the team needs to accomplish. If not, he will be bogged down by the tasks and lose the time and ability to provide product guidance and connect with the stakeholders.

To learn more about Product Owners, visit the Scrum Team Assessment.

Please share!

The Rules of Scrum: Your Product Owner is the sole and final decision-maker for when the team’s work is released to production, users or customers

Learn more about transforming people, process and culture with the Real Agility Program

The Product Owner has the sole authority on putting the work of the Scrum Team at the end of a Sprint into the hands of users. This means that at the end of a Sprint, after the Sprint Review has occurred, the Product Owner considers the state of the Product (features, quality, performance, etc.) and the state of the business/market, and decides if the product should be sent out. In an IT or web environment, this means deployment. For other types of software this might be live updates or sending out DVDs to customers. There should be no other individuals who have the authority to do extra releases without the Product Owners approval, nor should there be anyone who can stop a release from going out if the Product Owner makes that decision. If the Product Owner has this authority, it can create a high level of efficiency in addressing the needs of the business or the needs of the market. If the Product Owner does not have this authority, then it undermines their authority over the ordering of the Product Backlog (since that ordering becomes meaningless) and it undermines the broader organization’s ability to hold the Product Owner accountable for results.

To learn more about Product Owners, visit the Scrum Team Assessment.

Please share!

The Rules of Scrum: Your ScrumMaster consistently avoids doing hands-on technical work with the team

Learn more about transforming people, process and culture with the Real Agility Program

The ScrumMaster is focused on two main goals: to remove obstacles of all sizes and to help the team become better at using Scrum. Both of these jobs require much work and plenty of skill. To do this well the ScrumMaster will need to refrain from doing hands-on technical work. If the ScrumMaster does this then the team will be protected from interruptions, move faster, and feel supported. If the ScrumMaster doesn’t do this then the team will be interrupted often, become slow, and feel unsafe and in harms way. A ScrumMaster doing hands-on technical is wasteful and distracting.

To learn more about ScrumMasters, visit the Scrum Team Assessment.

Please share!

Comparison of OpenAgile with Scrum

Learn more about transforming people, process and culture with the Real Agility Program

OpenAgile is similar to Scrum in many respects. Both are systems for delivering value to stakeholders. Both are agile methods. Both are frameworks that deliberately avoid giving all the answers. So why would we choose OpenAgile over Scrum?

The most important difference is in applicability: Scrum is designed to help organizations optimize new software product development, whereas OpenAgile is designed to help anyone learn to deliver value effectively.

OpenAgile is an improvement over Scrum in the following ways:

  1. More effective teamwork and team practices, in particular the Consultative Method of Decision Making, and
    applicability over a larger range of team sizes from a single individual on up.

  2. Recognition of the individual capacities required for effective learning, namely Truthfulness, Detachment,
    Search, Love and Courage. Scrum acknowledges a separate set of qualities, but does not show how they systematically connect with the requirements of a Scrum environment.

  3. Systematic handling of more types of work beyond just “new artifacts” and “obstacles”. In particular, OpenAgile includes calendar items, repetitive items and quality items and acknowledges their unique qualities in a work
    environment. OpenAgile also provides a framework to include additional types of work beyond these five.

  4. Improved role definitions based on extensive experience.

    1. There is only one role defined in OpenAgile (Team Member) vs. three defined in Scrum (Team Member, ScrumMaster, Product Owner).

    2. There are multiple paths of service that allow Team Members and Stakeholders to engage with an OpenAgile team or community in different ways. There are five paths of service: Process Facilitation, Growth Facilitation, Tutoring, Mentoring, and Catalyst.

    3. The Process Facilitator path of service is similar to the ScrumMaster role with the following major differences:

      • is not responsible for team development
      • is not necessarily a single person, nor is it a required role
    4. The Growth Facilitator path of service is similar to the Product Owner role with the following major differences:

      • is responsible for all aspects of growth including value (like the Product Owner), and individual and team capacity building.
      • is not necessarily a single person, nor is it a required role
  5. Integration of principles and practices from other methods. Two examples suffice:

    1. From Crystal: creating a safe work/learning environment.

    2. From Lean: build quality in, value stream mapping, root cause analysis, standard work.

  6. OpenAgile allows interruptions during the Cycle. Scrum has the concept of Sprint Safety. This makes Scrum
    unsuitable for operational work and general management.

  7. The distinction between Commitment Velocity and other uses of the term “velocity” used in Scrum. Commitment Velocity is the historical minimum slope of a team’s Cycle burndown charts and determines how much work a team plans in its Engagement Meeting.

  8. Flexibility in the length a Cycle. Scrum requires that Sprints (Cycles) be one month in duration or less.
    OpenAgile allows a Cycle to be longer than that and instead provides a guideline that there should be a minimum number of Cycles planned in the time expected to reach the overall goal.

  9. The Progress Meeting in OpenAgile does not require people to take turns or directly answer specific questions.

  10. Avoiding conflict-oriented models of staff and management (Chickens and Pigs in Scrum).

  11. Terminology changes to be more clear in meaning and applicable beyond software. A comparative glossary is
    included below.

Another major difference between OpenAgile and Scrum is how the community operates. OpenAgile is an open-source
method that has a specific structure for community involvement that allows for continuous improvement of the system. Scrum is closed. It is closely managed by it’s founders and this has led to challenges with the method becoming dogmatic. OpenAgile is meant to constantly evolve and grow.

Comparative Glossary between OpenAgile and Scrum

OpenAgile Scrum
Cycle Sprint
Cycle Planning Sprint Planning and Sprint Review
Team Member Team Member or “Pigs”
Process Facilitator ScrumMaster
Growth Facilitator Product Owner
Work Queue Product Backlog
Work Queue Item Product Backlog Item
Cycle Plan Sprint Backlog
Task Task
Work Period Day
Progress Meeting Daily Scrum
Learning Circle w/ steps Inspect and Adapt”
Delivered Value Potentially Shippable Software
Stakeholders Chickens”
Five Types of Work:

New, Repetitive, Obstacles, Calendar,

– no equivalents –

User Stories, N/A, Impediments, N/A, N/A

Consultative Decision Making – no equivalents –
Sector / Community – no equivalents –

References on OpenAgile:



References on Scrum:



“Agile Software Development with Scrum” – Schwaber and Beedle

“Agile Project Management with Scrum” – Schwaber

“Scrum and the Enterprise” – Schwaber

Please share!

Using Agile to Run a Small Business – Five Types of Work

Learn more about transforming people, process and culture with the Real Agility Program

At BERTEIG, we used Scrum to run our business for quite a while – about one year.  Over that time we struggled with a few different concepts and practices.  As a Certified Scrum Trainer, I am very aware that Scrum requires us to use the framework itself to expose obstacles, rather than modifying Scrum to accommodate obstacles.  However, over the course of that year, it became more and more obvious that there is something fundamentally different between writing software products (where Scrum is fantastic) and running a business.  Scrum, the framework, just wasn’t good enough.

The main problem we had was with the types of work we encounter in running a business.  We noticed patterns in the types of tasks we had every Cycle (Sprint).  In this article I will look carefully at two of those types of work and then briefly describe the other three types of work.

We discovered that calendar items such as meetings, scheduled public events, and even personal appointments didn’t fit anywhere in Scrum’s Product Backlog or Sprint Backlog.  At first, we tried to think of this as an obstacle and force-fit these into the Product Backlog.  That didn’t work because that meant we couldn’t always prioritize by value.  Even if the Product Backlog had something more valuable in it than the scheduled meeting, we sometimes couldn’t change the dates of the meeting to accomodate the more valuable work.  So Calendar Items became a new category of work in addition to the new “features” that were in the Product Backlog.  (I say “features” in quotes because we were running a business not writing software.)

We also noticed that we were struggling with applying the concept of the Definition of Done.  This led us to explore the concept of Repetitive Activities.  For example, we need to clean our office on a regular basis – vacuum, water plants, take out trash, etc.  If we left that until it became more valuable than anything else on our Product Backlog we would have ended up with a disgusting work environment.  So we thought that this should be part of our Definition of Done.  The problem then became a more conceptual one: what were we doing that needed cleaning so that it would be considered done?  Well of course, it’s simply part of business operations.  Cleaning is not independently valuable.  We did decide that it was most cost-effective to outsource it, but it didn’t match the concept of Definition of Done as applied to the work in the Product Backlog.  That led to an insight: actually, we were looking at a new category of work: Repetitive Activities.  These are those activities that we need to do to sustain our business and which should become habits, or which should be automated or outsourced.

After identifying Calendar Items and Repetitive Items as types of work, we decided that we needed to look at the Product Backlog more carefully.  We decided that we needed to separate features, or as we called it “New Artifacts”, from defects or Quality Problems.  We also formalized the concept of a queue of Obstacles, which is mentioned in Scrum, but about which is given very little guidance.

So after over a three years of trying to use agile methods to run our business, we have finally come up with a stable and seemingly sufficient set of types of work:

  • Calendar Items
  • Repetitive Activities
  • Quality Problems
  • Obstacles
  • New Artifacts

We have written more about our experiences and their results in our e-book: The OpenAgile Primer.  If you are trying to use agile methods to run a business or any other kind of organization, please check it out and let us know about your experiences.  We hope that OpenAgile will become an Open-Source method that we can contribute back to the world of work and life.  OpenAgile for business is a great match and is, in our experience, a much better fit than Scrum or Kanban.

Please share!

What is Agile?

Learn more about transforming people, process and culture with the Real Agility Program

The word “Agile” refers to a type of method for getting work done.  It’s all about doing valuable work with speed and quality.  An Agile team delivers finished work frequently while working at a sustainable pace.  Agile process consists of short iterations of work that deliver small increments of potentially shippable customer value.  Frequent delivery ensures visibility of the work of the team, as well as its needs and obstacles, to all stakeholders.

Agile refers to a discipline defined as the middle way of excellence between chaos and bureaucracy.  Agile also refers to the philosophy that humans do work in a complex world.

Although Agile has emerged out of endemic crisis in the software development sector (but not exclusive to it!) – mainly caused by the pressure built up from the strata of systemic dishonesty and distrust – it is not a software development process methodology.  Rather, it is a system of learning that challenges deep cultural assumptions and catalyzes change in an organization.

Agile methods are made of processes, principles and tools.  But most importantly they are concerned with people.  Therefore, Truthfulness is the foundation of success in an Agile organization.

Although Agile cannot force people to be truthful, it reveals the direct consequences of opacity in an organization, confronts it and challenges it to change.

Agile prioritizes by value, not “dependency”.  In fact, Agile teams are expected to break dependencies and are empowered by such challenges.  Agile teams self-organize their own work –  they are not “managed resources”.  Agile is team-focused rather than project-focused.  Agile responds to evolving requirements and avoids frozen requirements.  In an Agile environment change is embraced as natural and healthy, rather than as something “risky” to be avoided.

In short, Agile is about overcoming fear, both on the part of individuals as well as collectively and culturally on the part of organizations.

As with any sincere effort to overcome habitual fear, Agile work is hard work.  Becoming Agile can be an uncomfortable, confusing and frustrating process and can remain that way for a long time.

Agile is the art of the possible.  It’s methods are idealistic, not dogmatic.  Agile is about learning, adapting and striving for the ideal.  Agile is based in reality – it relies on everyone to be truthful about the possible and to contribute honestly towards customer value.

Therefore, Agile requires a constructive and positive attitude.  In an Agile environment, a state of crisis is an embraced opportunity to learn and improve.

An Agile team is empowered by its responsibility to self-organize.  On an Agile team, people work together towards a common goal and coordinate their work amongst themselves.  There are no managers or bosses on Agile teams.  Correspondingly, no member of an Agile team reports to a boss or a manager.  All team members report to the team.  While working on a team, everyone checks their institutional titles, roles and responsibilities at the door.  All members of an Agile team are responsible for one thing: contributing as much customer value as possible to the work of the team.

Agile exposes the true character of an organization’s culture and forces visibility on all levels.

At Berteig Consulting, we practice Agile.  I am currently working in the role of Process Facilitator for our core team of 4.  We work in 1-week iterations.  As a couple of the team members have a 4-day work week, we have our Retrospective on Monday mornings at 10 AM, followed by the Planning Meeting for our next iteration at 11 AM.  The remaining work days begin with a daily stand-up meeting using the reporting methods of the Daily Scrum (each member reports 3 things to the team – “What I did yesterday”, What I’m doing today”, and “What are my obstacles”).  We work in a collocated team room, with product backlog items, iteration backlog tasks, obstacles, definition of done and a burn-down chart all up on the walls.  We are currently in our fourth iteration of our current project (which, in this case, is the business itself!).  As part of our retrospectives, team members actually demo finished work – i.e., Mishkin shows us some of the great changes he’s made to his course materials and Paul demos the latest edition of our beautiful newsletter (the one you’re reading right now!).  Laila has even demoed some travel tools that she’s been working on for the coaches and trainers.  We also decided to each write our reflections in order to share them with those who might find it useful as a way of wrapping up the retrospective for this iteration.

Agile can be implemented anywhere people do work together.  Visibility of work, openness of consultation and a strong collaborative spirit feeds an overall feeling of excitement and optimism on an Agile team.  Clear goals based on small pieces of prioritized value and sustainability of work ensure quality and speed of productivity.  But of course, in order for a team to build up these capabilities, it must establish, maintain and defend a firm and immovable foundation of truthfulness.

Please share!

First Interation Ending

Learn more about transforming people, process and culture with the Real Agility Program

My first iteration using Agile Work for my business development has come to a close. Here is what I did for a “demo” and retrospective.

Continue reading First Interation Ending

Please share!

My First Challenge

Learn more about transforming people, process and culture with the Real Agility Program

Wednesday is nearly done and I’m looking at my list of tasks and cringing! I’ve only done a few out of the forty for this week. What’s going on?!

Continue reading My First Challenge

Please share!

Can dying plan-based projects be recussitated?

Learn more about transforming people, process and culture with the Real Agility Program

We’ve all seen this. A one-year project in its 13th month, and the Project Manager has been reporting 80% of the tasks at 90% and has been doing so for the last 120 days. There’s no end in sight, and the customer is leaking cash every day the product fails to go into production. What can be done? Agile project management principles can help this all-too-frequent scenario.

Continue reading Can dying plan-based projects be recussitated?

Please share!