Tag Archives: principles

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.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

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

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

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.
Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Manifesto and Enterprise – Rant and Rave (Session Proposal)

I’ve proposed a session called “Agile Manifesto and Enterprise – Rant and Rave” for the Toronto Agile Community’s conference “Toronto Agile and Software“.  The session is based loosely on my earlier article “The Agile Framework: Agile Values and Principles, The Agile Toolkit, The Agile Organization“, as well as some of the things that I do in the 2nd day of my Certified Scrum Master training session.  If you are thinking of coming to the conference, I would greatly appreciate your votes or feedback on my session proposal!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

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.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Three Fundamental Principles of Agile Estimation – The Third One Will Surprise You!

You probably already use an Agile Estimation technique such as the Planning Game or the Bucket System, but surprisingly few people understand the underlying principles of Agile Estimation.  This lack of understanding often causes confusion or stress for the people who try to use Agile Estimation techniques.  The discrepancy between traditional estimation techniques and Agile techniques is large and it is hard to bridge that mental gap without understanding the principles involved.  There are three fundamental principles of Agile estimation:

Principle One: Collaborative

Agile estimation methods are collaborative.  This means that multiple people work together to arrive at estimates for work in an Agile project or product development effort.  Traditional estimation techniques (such as those related to bottom-up or top-down) tend to focus on individuals estimating the work that they are responsible for doing and “trusting” those individual estimates.  Collaborative estimation means that most estimation is done by people in formally facilitated meetings where people are present in-person.

Collaborative techniques are generally used where there is some expectation that multiple minds are better than a single mind in discovering some new knowledge or solving a problem.  Teamwork and groupwork are based on this concept.  This idea of collaboration for problem solving is also applied to Agile Estimation and it has some interesting ramifications.

The most radical consequence of collaborative estimation methods is that there is no possibility to trace a particular estimate for a particular item to a particular individual person.  This lack of traceability is important to create a sense of safety on the part of participants in the estimation effort.  This safety is necessary to allow participants to be fully honest about estimates even if those estimates conflict with expectations of powerful stakeholders.  Another way of stating this principle is that no individual can be punished for a bad estimate.

Many Agile estimation techniques take this principle beyond just mere collaboration to the level of consensus-building techniques where everyone in a group doing estimation work must agree on the final estimate for each and every item being estimated.  This strengthens the idea of safety to the point where no participant in an estimation effort can ever say “I didn’t agree with that” and thereby leave other participants “on the hook” for a bad estimate.

Principle Two: Relative Estimation

Imagine you are shown a glass bottle with some water in it.  You can see the water sloshing around.  Someone asks you, “how much water is in the bottle?”  You might, at first, think about the overall size of the bottle and respond by saying “it’s 1/3 full.”  Or, if asked to provide a measure in units like millilitres or fluid ounces, you might mentally compare what you see in front of you to some container (e.g. a measuring cup) where you know the quantity.  In both cases, you are doing a relative estimate of the amount of water in the bottle.  You are comparing the amount of water to a known quantity.

Imagine a counter-example: someone walks up to you with a red pen ask asks you “what is the wavelength of the light being reflected from this red ink?”  If you are like most people, you have probably forgotten (if you ever knew) the wavelengths of light in the visible spectrum.  You have no basis for comparison.  You might take a wild guess, but it is just that.  Going back to our relative measure, you might be able to easily say if it is darker or lighter than another red colour, or you might even be able to tell what hue of red it is.  But those cases are, again, relying on our inherent ability to see relative differences.

So instead of ignoring this capacity, in Agile estimation techniques, we leverage it.  When estimating effort, we start by setting a clear baseline for what we are comparing: another piece of work.  The baseline piece of work is often given an “estimate” that is arbitrary and in some non-standard units.  For example, it is common to use “points” when estimating the effort for Product Backlog Items.

When doing relative estimates it is very important to ensure we are comparing “apples to apples”.  Both the piece of work to be estimated and the comparison piece should both be work items that are not yet done!  If you have already completed one of the pieces of work, you have prior knowledge that you don’t have for the work to be estimated.

This last point is subtle, but important.  If you have already done something, you know much more about it.  If you try to compare to something you haven’t yet done, you will be tempted to assume that the two things will be more similar than they may be when you actually get to work on it.  By comparing two pieces of work that you have not yet done, you become much more conscious of the risks of comparing, and that consciousness will help you make better relative estimates.

It is important to note that one side advantage of using relative units for estimation is that it makes it much more difficult to use estimates as a baseline for either measuring performance or for tracking schedule variance, both of which are essentially meaningless in a good Agile environment (which should be almost entirely results-oriented).

Principle Three: Fast

In Agile estimation we don’t care (!!!) about accuracy nor about precision of estimates.  Whoa!  Why is that?  Because estimation is waste.  You can’t sell estimates, and estimates don’t affect the “form, fit or function” of the thing you’re building.  Therefore, both Agile and Lean concur: do your utmost to eliminate that waste.  There are actually lots of Agile practitioners who think estimates are evil (and they have some good arguments!)

In order to do Agile estimation in a maximally non-evil way, we need to make estimation fast!  Really fast!!!  Many of the Agile estimation techniques allow you to estimate a product release schedule lasting as much as a year in just a few hours given a reasonably well-crafted Product Backlog.

There are really only two modestly good reasons for doing estimation in an Agile project or product:

  1. Estimates provide simplified information to the Product Owner to allow him/her to make sure the Product Backlog is ready for the next Sprint (ordered, refined).
  2. Estimates allow stakeholders, including the team doing the work, to generate high-level common understanding and expectations without dwelling on details.

As a business stakeholder, one can do a simple mental exercise.  Ask yourself, “how much money would I be willing to spend to accomplish those two objectives?”  Whatever your answer, I hope that it is a very small amount compared to what you are willing to spend on getting results.  If not, perhaps you haven’t really embraced the Agile mindset yet where “the primary measure of progress is working software” (the Agile Manifesto).

Bonus Principle: We Suck at Estimating

Most people doing estimation in traditional project management try to measure in units like person-days or dollars.  There is no doubt that these units are useful if you can get good estimates.  However, most of the people doing estimation are fundamentally and irredeemably bad at it.  How do I know?  Because they are not wealthy… and have thereby proven that they cannot predict the future.  If you can predict the future, even just in limited circumstances (like estimating effort or revenue), you can leverage that to generate almost untold wealth.  Given that, it is fruitless and wasteful to try to get better at estimating.  Instead, the principles of Agile estimation help us focus our attention on the right things: collaboration, comparative estimates and doing them fast so we can get to the real work, and most importantly: delivering valuable results now.  Understanding these principles helps teams overcome many of the struggles they have in using Agile estimation techniques.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: I live the values and principles of the Agile Manifesto in my team

The Agile Manifesto is the founding document of the Agile movement.  It can be found at http://www.agilemanifesto.org and if you haven’t read it, it is strongly recommended!  Living values and principles is an act of striving for excellence.  There are no mechanisms in Scrum to force people to live the values and principles of the Agile Manifesto. Scrum relies on individual team members to strive to develop an understanding and practice of Agile values and principles in and of their own volition.  If Team Members do not live the values and principles of the Agile Manifesto in their team many other things will take priority such as creating a complex document.  The team could think of Scrum as a tool for project delivery, without really working to change the culture of their organization.  Since Scrum empowers individuals and makes obstacles visible, if the team doesn’t live the Agile Manifesto principles then they may be disconnected from the roots of Scrum and make it a lesser version of itself, sometimes known as Scrumerfall (where you blend some elements of Scrum with other elements of waterfall which provides little to no benefit).

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

What is Agile?

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.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail