Archive for the ‘How-To Apply Agile’ Category

New Certified Scrum Product Owner training in Toronto added to calendar

Wednesday, November 4th, 2009

Due to popular demand, we have added another Certified Scrum Product Owner (CSPO) training to our listing of courses.  There is an overwhelming need for well trained Product Owners, and we’re happy to take up the challenge. The next CSPO will happen on January 14 & 15 at our office in Newmarket, just north of Toronto.

During this seminar, our Certified Scrum Trainer will teach participants how to do the fundamental tasks of the Product Owner in the Scrum environment.  The attendees will learn:

  • how to develop a comprehensive Product Backlog
  • competently add value to the Scrum team during the Sprint
  • fully understand how Scrum works and their role within the agile environment

With a maximum class size of five people, this seminar is designed to allow participants to dig deep into the role of the Certified Scrum Product Owner. After completing this course, attendees of this seminar will be able to create and manage a Product Backlog, work with a Scrum Team to create high-quality software, and use the Scrum framework to build and deliver the right software.  Please refer to our website for a course description and to reserve space for yourself or others on your team. http://www.berteigconsulting.com/CSPOCourseDescription

We look forward to adding value to your team!

If you would like more information contact us at sales@berteigconsulting.com

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Seven Essential Teamwork Skills

Monday, October 12th, 2009

I’ve been researching teamwork lately.  I just finished reading “The Discipline of Teams” by Katzenbach and Smith which is an HBR summary of their much more substantial book “The Wisdom of Teams”.  I decided that it would be good to be able to describe the essential skills an individual needs to acquire in order to work effectively in a team.  First stop, Google and a search of “list of teamwork skills”.

Strangely, not much turned up on the first page.  The best result is found at “7 Essential Skills for Teamwork” which is a page on a public elementary school web site.  So, here’s my adaptation of their list:

Active Listening

Active listening is a skill that allows a person to completely focus on the communication of another person including both verbal and non-verbal aspects.  Active listening requires the ability to not think of your own responses until after a person has finished speaking.  One simple way of doing this is to echo what a person is saying in your silent internal voice.  When someone says “I think we should build a new gimbal on the widget”, you are saying exactly the same thing in your own mind.  Active listening also requires that you request clarification, often by rephrasing what a person has said and asking if you have understood correctly.

Questioning

Being able to frame and express questions effectively helps us understand and integrate knowledge into our own mental model of the world, or even to modify our mental model.  Asking questions is easy.  Asking good questions is much harder.  We need to use an appropriate set of words and tone of voice so that we do not alienate or offend the recipient of the question.  For example, asking “why did you do that?” will often put people on the defensive since they will assume that you mean you disagree with their actions.  Instead, saying “I do not understand the reason you did that.  Could you please explain it to me?” can be a much more gentle way of getting to the same information.

Logical Argument

When presenting an idea or position, being able to logically support it is important to exploring the truth of it.  This includes being able to share your assumptions or axioms, the data you are basing your argument upon, and the logical sequence of reasoning to reach your conclusion.  Being able to avoid fallacious logical methods is also important.

Respecting

Showing respect includes acknowledging the fundamental human value of the existence of your teammates, and being able to step back from your own understanding of the world to acknowledge the legitimate nature of the perspective that other people have.  This does not mean that you have to let teammates get away with inappropriate behavior.  In fact, respect for your teammates will allow you to support them in behaving in ways that are in alignment with their fundamental nobility as human beings.

Helping

Offering help and actually following through with real assistance are aspects of helping.  When you suspect that a team member is struggling with something, you offer to help both verbally and with your actions.  This can take the form of offering information, offering emotional support, offering to assist with problem-solving, or actually taking action to do an activity together.  When we help someone, we share their burden.

Sharing

Sharing our knowledge, time, skills or physical resources are all aspects of sharing.  Sharing among team members is focused on those things which will help a team reach its goals.  This is similar to helping except that it tends to be more of a transaction than an ongoing activity.  The transaction is that you give a gift and then the other person uses that gift to meet their needs.  Sharing does not require reciprocity.  If you share something with another person, you should not expect that that person will return the gift at any time in the future.

Participating

It’s probably obvious, but in order to effectively be on a team, you need to participate!  Participation itself is mostly obvious: do work with the other team members.  However, there are also some less obvious aspects of it.  You are not participating when the team is having a discussion, you find it boring, so you check your email.  You are not participating when the team makes a decision and you abstain from helping to execute the decision because you disagree.  You are not participating in a work team when you are mentally checked out because of a crisis at home.

All of these skills are critical teamwork skills… but there may be others.  Do you think there are other skills missing from this list that are critical for effective teamwork?

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Agile method for the Financial Services industry

Tuesday, June 30th, 2009

There are two things every leader needs to know to be successful: first, a leader must clearly articulate what they expect, and second, they need to inspect what they expect on a daily basis. The big challenge though is how do you stay on top of changing priorities? And how do you avoid micro management and driving your team crazy?  This is why OpenAgile, in my opinion, will be very quickly embraced by management teams around the world. It has all the necessary tools to ensure success.
 
For the past 6 months, I have been working with a financial services team in Slovakia to introduce them to Agile methods. I started with Scrum, a methodology and framework that has been used in the Information Technology sector for the past 5-10 years.
 
The Slovak team started using Scrum with one team of 6 managers. They grew to have 4 teams actively managing their activities and projects using Agile Scrum, and another 2 teams are planning to launch soon. The feedback from the team members has been positive and the team leader is very impressed with the methodology, the activity levels, and the results. This organization/structure is doing very well in the very competitive marketplace that is Slovakia. I interact with the teams on a regular basis and often travel to Slovakia from Canada on business, so I have the opportunity to work closely with the structure, leader, and the teams.
 
The only challenge with Scrum is that it is somewhat restrictive regarding the types of work that is recorded and reported upon. Scrum does not accommodate repetitive or calendared activities. Fortunately, Berteig Consulting has developed OpenAgile as a new Agile method that allows for the tracking and reporting of all the Scrum work activities plus these new categories. I find OpenAgile more inclusive and representative of the Financial Services work environment.  
 
I’m now in the process of transitioning the Slovak teams from Scrum to OpenAgile. I believe OpenAgile will be a much better methodology for this team, and for all non-IT organizations, as it creates an environment for teams to achieve even greater success.
 
The OpenAgile method teaches the team members to self-manage. And rather than replacing the role of the team leader, that person is empowered to truly lead because they are free to focus on creating an environment where the team can thrive. OpenAgile helps the team to clearly identify the key strategic and tactical goals, and it allows the team to systematically inspects what everyone expects to be done.

There is actually a third thing every leader needs to know. It’s called OpenAgile.  And you can learn more about OpenAgile at http://www.openagile.com/ or by contacting Berteig Consulting http://www.berteigconsulting.com/Contact

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Why try to be good?

Monday, June 29th, 2009

What motivates human beings to do the right thing?  To do good deeds, to be truthful, to be kind, to be helpful, to try to make the world a better place?  First of all, we have to realize that everything we say and do has an actual, real effect on our environment for better or for worse.  Every time we help someone, or tell the truth, it actually makes the world better in some small way, just as when we lie, cheat, steal or speak unkindly to someone, no matter how small the affront, we actually make the world worse.  In fact, our thoughts, words and actions can really have only one of two basic effects on the world – they can make it better or make it worse.  Period.

There are some powerful cultural forces in our society, most obviously the constant stream of materialistic propaganda through various forms of hypnotic media, that influence the way we perceive our ability to contribute to the betterment or worsening of our environment.  The basic message is that individuals can’t affect any real fundamental change in society (i.e., their environment) and that the best any of us can do is to change our position, rank or class within the permanent structures of our society.  Therefore, “only the strong survive”, “get what you can while you can” and the “pursuit of happiness” have become not only slogans that we live by, but conceptions of human nature that have constructed our social reality.

For example, the concept behind “the pursuit of happiness” is that happiness is something external and fixed that a person has to find somewhere “out there”.  Embedded in this “right” is the implicit message that “average” individuals and groups do not have the potential to exert influence on, and contribute in any meaningful and lasting way to the shaping of the prevailing social order.  Thus, there is always a better neighborhood to live in, a better employer to work for, a better school for your kids to go to, etc.  It disempowers us all from thinking that we can get together and do something right now about our immediate reality.  ”Don’t even bother”, it says, “you won’t be able to change anything anyways – you’re wasting time, effort, and worst of all – money!  Better to lie just a little, cheat just a little, step on your neighbor just a little in order to protect your own little piece of turf.”

Understanding the truth about our reality – our potential to contribute to the betterment of the world – is what will actually begin to motivate us to be good – that is, the fact that our good thoughts, good words, and good actions can and do make the world better.  ”Better” becomes not merely an external pursuit that we fight to get our little piece of; rather, it is an organic, sembiotic process of growth.  For one thing, it requires vision: What would the world be like, for example, if everyone always tried to tell the truth?  Would it really be so bad?  Would human affairs come to stand still?  Would the economy crumble?  Or would it, rather, begin create something new… something better?

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Scrum Study Guide updated with tools for new ScrumMasters

Wednesday, June 10th, 2009

We’ve updated the Scrum Study Guide and lowered the price!  The Scrum Study Guide is an editable tool for helping ScrumMasters do their jobs.  It is like a personal assistant that helps you:

  • Keep track of the rules of Scrum
  • Find tons of concise how-to guides for common steps and activities in doing Scrum
  • Keep structured notes or a journal on your job as the ScrumMaster
  • Maintain a list of online reference material
  • Assess the progress of your team
  • Organize the obstacles you are working on
  • Modify and update the Scrum reference material based on how you are actually doing Scrum
  • Look up answers to the problems you’re having with your organization
  • Plus, every time we update content, pictures, tools, and best practices, you get the updates for free for the rest of your life!

    www.scrumstudyguide.com

    Are you one of the many satisfied Scrum Study Guide customers?  Tell us how it is working for you.

    Share and Enjoy:
    • TwitThis
    • LinkedIn
    • Digg
    • Technorati
    • del.icio.us
    • Propeller
    • StumbleUpon
    • Reddit
    • Fark
    • Slashdot
    • Blogsvine
    • Google Bookmarks
    • Furl
    • Facebook
    • BlinkList
    • YahooMyWeb

    Growth Facilitator role on an OpenAgile team

    Friday, June 5th, 2009

    This is my first post on the Agile Advice blog.  In fact, it’s my first blog post ever.  Before joining the Berteig Consulting team, I had never even heard the words Agile, Scrum, Lean, or OpenAgile.  After all, my background is marketing, community relations, and sustainability!  Needless to say, I’ve gone through some intense learning about the role of the Growth Facilitator.

    The responsibility of the Growth Facilitator is about more than simply prioritizing New Work goals and tasks. I see the role as contributing to the organizational culture, and helping to build the business in a sustainable way. “Sustainability” is an important concept at BCI. It means that we are committed to conducting business in a way that is respectful of the environment, society, and the economy. At the same time, it means that the BCI team operates at a sustainable pace, finding ways to balance our work and life so that we don’t burn out.

    As Growth Facilitator, I am also responsible for guiding the team toward delivering greater value for our stakeholders. At Berteig Consulting, our stakeholders don’t just include the company’s owners. Our stakeholders include a wide range of groups, including customers, suppliers, employees, and our families, all without whose support nothing we do would be possible. Delivering value to our stakeholders requires that we keep them in mind when we commit to our tasks each week.

    One of the important lessons I learned was to give the team S.M.A.R.T. – Simple, Measureable, Achievable, Relevant, and Timebound – goals and give them space to come up with the tasks to meet the goal. When I first started, I made goals that were broad, saying for example “to take care of our clients” or “to work at a sustainable pace.” Rather than stating goals, I realized that I was making statements of the team’s shared values. And while the team integrated these thoughts into our behavior, it was nonetheless challenging to spin off specific tasks that we could work on. Now, I try to ensure the goals I create conform to a user story format and meet S.M.A.R.T. criteria. For example “Berteig Consulting can update the Certified ScrumMaster course content so that all CSM course participants receive the best value in the market.” As soon as I made the direction clear, the team self-organized and generated tasks required to achieve each goal.

    Another key lesson of developing the direction for the team was allowing the Team Members time to review the next Cycle’s goals in advance of the Cycle Planning Meeting so that they could provide feedback and seek clarification. This became particularly important when one team member jumped on a business opportunity that created a significant amount of New Work. We simply could not overlook this great opportunity, and we moved it to the top of the New Work priority list and put it in the next Cycle Plan.

    Last, I learned that the Growth Facilitator and Process Facilitator have a complimentary relationship that requires frequent consultation. As the Process Facilitator goes about helping the team overcome obstacles, it can become clear that the team needs to address a systemic challenge during one of the upcoming Cycles. The Growth Facilitator then states the need as a Cycle goal in a S.M.A.R.T. format, allows the team time to give feedback, and prioritizes the goal in the New Work list. When the goal is brought to a future Cycle Planning Meeting, the team breaks the goal into tasks and solves the systemic obstacle that the Process Facilitator identified.

    These lessons have helped me understand how the Growth Facilitator role extends beyond prioritizing New Work and guiding the team’s value delivery. The role also fosters the culture in which the work gets done – working at a sustainable pace, taking care of our customers, and maintaining unity of vision.

    I would love to hear your thoughts about anything I’ve expressed here. Berteig Consulting is a deep-learning environment, and your feedback is invaluable.

    David D. Parker
    VP Marketing and Sustainability
    Growth Facilitator

    Share and Enjoy:
    • TwitThis
    • LinkedIn
    • Digg
    • Technorati
    • del.icio.us
    • Propeller
    • StumbleUpon
    • Reddit
    • Fark
    • Slashdot
    • Blogsvine
    • Google Bookmarks
    • Furl
    • Facebook
    • BlinkList
    • YahooMyWeb

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

    Thursday, May 14th, 2009

    At Berteig Consulting, 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 Work.  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 Items.  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 Work”, from defects or Quality Items.  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 Items
    • Quality Items
    • Obstacles
    • New Work

    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.

    Share and Enjoy:
    • TwitThis
    • LinkedIn
    • Digg
    • Technorati
    • del.icio.us
    • Propeller
    • StumbleUpon
    • Reddit
    • Fark
    • Slashdot
    • Blogsvine
    • Google Bookmarks
    • Furl
    • Facebook
    • BlinkList
    • YahooMyWeb

    Agile Beyond Software Yahoo Group Created – Please Join!

    Tuesday, March 17th, 2009

    I’ve just created a Yahoo! group called “Agile Beyond Software“.  From the group description:

    This is a group for people who are interested in sharing stories, experiences, practices, and questions about applying agile beyond software. This could be in management, marketing, engineering, small business, personal life, community groups, or any other areas where you think it might be worth trying!!!

    We welcome people trying to adapt any of the specific agile methods. It could be Scrum, XP, Lean, DSDM, FDD, AgileUP, etc…

    Please join this group if you are interested in exploring this topic.  As well, if you know people who are doing this, please consider inviting them to join as well!

    Thanks!

    Share and Enjoy:
    • TwitThis
    • LinkedIn
    • Digg
    • Technorati
    • del.icio.us
    • Propeller
    • StumbleUpon
    • Reddit
    • Fark
    • Slashdot
    • Blogsvine
    • Google Bookmarks
    • Furl
    • Facebook
    • BlinkList
    • YahooMyWeb

    Agile Successes and “Failures”

    Wednesday, February 18th, 2009

    Here are the results from a bit of web research that I just did for a client:

    Successes:

    Capital One:

    Agile 2007 Conference Presentation – “The Growth of an Agile Coach Community at a Fortune 200 Company”

    *Mishkin Berteig (http://www.berteigconsulting.com/MishkinBerteig) worked with co-author Kara Silva on a large-scale Agile implementation

    2005 Information Week article

    Salesforce.com:

    Agile 2007 Conference Presentation

    “Failures“:

    It’s generally really hard to get people to talk openly about failure.  I assert that Agile itself never fails, rather organizations fail to implement Agile.  But that’s for another article. Here are some anonymous stories:

    http://www.agileadvice.com/2007/08/09/agile-case-studies/a-cautionary-tale-delaying-agile-adoption/

    http://www.cio.com/article/442264/Cargo_Cult_Methodology_How_Agile_Can_Go_Terribly_Terribly_Wrong

    This one includes successes and failures in China:

    http://www.infoq.com/articles/Agile-adoption-study-china

    Another interesting article about the concept of failure:

    http://blogs.zdnet.com/projectfailures/?p=494

    So cheeky, so true:

    “How to Fail with Agile” by Clinton Keith & Mike Cohn

    Interviews on adopting Agile:

    http://www.infoq.com/bycategory/contentbycategory.action?idx=2&ct=2&alias=adopting-agile

    Share and Enjoy:
    • TwitThis
    • LinkedIn
    • Digg
    • Technorati
    • del.icio.us
    • Propeller
    • StumbleUpon
    • Reddit
    • Fark
    • Slashdot
    • Blogsvine
    • Google Bookmarks
    • Furl
    • Facebook
    • BlinkList
    • YahooMyWeb

    Agile Guidance Engineering – Applying Agile to Writing Projects

    Sunday, February 8th, 2009

    Thanks to Christian Gruber of Geek in a Suite for pointing me to this fascinating use of agile on writing projects: Agile Guidance Engineering.

    Share and Enjoy:
    • TwitThis
    • LinkedIn
    • Digg
    • Technorati
    • del.icio.us
    • Propeller
    • StumbleUpon
    • Reddit
    • Fark
    • Slashdot
    • Blogsvine
    • Google Bookmarks
    • Furl
    • Facebook
    • BlinkList
    • YahooMyWeb

    Agile Productivity Measures

    Monday, February 2nd, 2009

    Scott Ambler has written a couple good articles about measuring productivity with velocity.  Acceleration: An Agile Productivity Measure. and Examining Acceleration.

    From what I understand, this is a measure of the effect of agile on the relative improvement over time of a team.  I would beg to differ that it is a measure of productivity.  Productivity is value delivered over time.  If team A is delivering $5/week and team B is delivering $5000/week, then knowing that team A is accelerating faster than team B isn’t terribly important, particularly if the market can’t bear to absorb $6/week of whatever team A is producing.

    Measuring productivity is hard.  I would love to hear from people who have tried various means to measure productivity.  I measure productivity in our business, but I can do that because we are small and everything we do has a direct effect on the bottom line.  Does your business run with that transparency?  If not, why not?

    Share and Enjoy:
    • TwitThis
    • LinkedIn
    • Digg
    • Technorati
    • del.icio.us
    • Propeller
    • StumbleUpon
    • Reddit
    • Fark
    • Slashdot
    • Blogsvine
    • Google Bookmarks
    • Furl
    • Facebook
    • BlinkList
    • YahooMyWeb

    Lateral Violence and Workplace Safety – Awareness for Agile Teams and Coaches

    Monday, January 26th, 2009

    Two very interesting videos.  The first, a presentation by Rod Jeffries, goes through a treatment of “Lateral Violence”.  The second is three role-play scenarios to demonstrate the concepts.  Both of these videos are in the context of nursing in hospitals… however, it takes little imagination to see how they apply in other environments.  I would actually assert that the problems described in these videos are endemic to most organizations.

    Alistair Cockburn has also written about safety in a team context.

    Scrum and other agile methods all have some mechanisms for dealing with this sort of challenge, but they can start failing quickly if the sponsors of the agile effort do not overcome the habitual and cultural challengs.

    Share and Enjoy:
    • TwitThis
    • LinkedIn
    • Digg
    • Technorati
    • del.icio.us
    • Propeller
    • StumbleUpon
    • Reddit
    • Fark
    • Slashdot
    • Blogsvine
    • Google Bookmarks
    • Furl
    • Facebook
    • BlinkList
    • YahooMyWeb

    Changing Patterns of Thought for Defining and Expanding Done

    Monday, January 26th, 2009

    “Without changing our patterns of thought, we will not be able to solve the problems that we created with our current patterns of thought.”  -Albert Einstein

    “We are what we repeatedly do. Excellence, then, is not an act, but habit.”  -Aristotle

    Among leading Agile thinkers, coaches, trainers and practitioners there is a rich, ongoing discourse around a subtly deceptive concept  – the concept of the Definition of Done.  Within this discourse, a singular constant challenge is emerging:  old patterns of thought.

    For example, there is an old pattern of thought that tells managers of software companies that at least some part of the Definition of Done must be imposed on teams in order to protect a universal standard.  Rationalizing this antiquated thought pattern seems to have become a rigorous intellectual discipline in and of itself.  One of the most prevalent excuses to which many managers have invested a great amount of mental and emotional energy seems to be around the challenging concept of multiple Agile teams working together on the same project (or product).  Surely, in such cases there needs to be some kind of imposed standard that all teams need to comply with in order to avoid chaos in the main build, yes?  In fact, this is the exact wrong approach to take.

    We also seem to become confused at times by our own limited understanding of the words that we use when attempting to talk about things we are or are not trying and learning to do.  The more we learn about doing something, the more we are able to talk about it in practical terms.  Since theoretical discussions around semantics rarely result in appreciably improved behavior/results, we will endeavor here to address this subject with both brevity and caution.

    Our old patterns of thought make understanding many words, including the word definition and the word done, problematic.  We tend to think of these words as implying static, rigid, absolute conditions; for example, the way we tend to think of the word definition in terms of the definitions of words.  We like to think that those definitions are relatively stable.  Indeed, there are some real benefits to this.  We can have conversations with people and assume that for the most part their understanding of the definitions of the words we are using are similar to our own.  But even with words, there can be more than one definition, which already makes the definitions of words less static than they often seem.  At some level, one might even ask – who actually decides on the definitions of words?  Is there an actual authority out there (not merely the self-proclaimed “official” authorities) that decides on definitions and hands them down to us?  Some may say “yes, indeed, namely the authoritative texts of the world’s religions,” for example.  On the other hand one could also say that the definitions of words have evolved through the ages (just as languages have) as humanity has received progressively more complex guidance from religious texts according to its evolving capacity (compare, say, the Bhagavad Gita to the Quran).  But that is another conversation.  What is important to acknowledge here is that the meanings of words expand and evolve over time given the capacity of the individuals who use them to develop new patterns of thought and that the energy required to do so is tremendous, even epochal.

    An old pattern of thought construct around the word done is equally problematic.  A conversation limited by a rigid understanding of the concept of what done means, is and looks like can quickly take us spinning off into the stratosphere of “nothing is ever done.”  When there is a lack of trust and respect among people, as is generally the case in our society, and since ownership and ego are often entangled with limited and rigid understand, we then find ourselves in situations in which the limited and rigid understanding of a few with arbitrary power and authority take precedence over the understanding of others.  In other words, people in authority are expected to solve every problem and people that do work are expected to be robots.  Both are set up by this arrangement to fail.

    Indeed, there is a real problem in trying to talk about things that we do not do, or that we do not sincerely try to do.  True learning, on the other hand, consists in people striving to be truthful and sincere working together  engagement in a continuous cycle of action, reflection and consultation.  Learning also requires us to be truthful – if we think we have all the answers, learning becomes extremely difficult, if not impossible.  If we are not at least trying to learn to define what “done” is to us, we will never be able to actually talk about it in a knowledgeable and meaningful way.  Furthermore, it will likewise be impossible for us to help anyone else learn to understand their own Definition of Done if we haven’t learned through real experience about how to understand our own.

    As we engage in a real learning process, through action, reflection and consultation, new patterns of thought begin to emerge and perhaps even crystallize.  These emerging new patterns help us to bring concepts out of the stratosphere of semantics, rhetoric and theory back down to earth where we can actually act and reflect on them in order to implement creative new solutions to the problems of our world.

    In her Agile 2007 presentation The Role of Leadership in Software Development (http://www.infoq.com/presentations/poppendieck-agile-leadership), Mary Poppendieck offers powerful insights into the history of patterns of thought around leadership and the emergence of Agile thinking out of the wisdom of Lean Manufacturing.

    As with all Agile methods, Scrum is a framework for learning in which new patterns of thought that began to crystallize in Lean Manufacturing practices have been adapted and applied to software development practices.  It then follows that the Definition of Done in Scrum is consistent with a specific Lean Manufacturing practice, namely Standard Work.

    In his book Workplace Management, Taiichi Ohno, the father of Lean Manufacturing, defines Standard Work as such:

    “There is something called standard work, but standards should be changed constantly.  Instead, if you think of the standard as the best you can do, it’s all over.  The standard work is only a baseline for doing further kaizen [change for the better].  It is kai-aku [change for the worse] if things get worse than now, and it is kaizen if things get better than now.  Standards are set arbitrarily by humans, so how can they not change?

    “You should not create these away from the job.  See what is happening on the gemba [shop floor] and write it down.”

    Based on the assertions of the previous two paragraphs, we must conclude that just as standards should be changed constantly in Standard Work, so too should definitions change constantly in the Definition of Done.

    How, then, does our work benefit from a Definition of Done that is always changing?  This is a deceptively simple question, as it is an example of a problem posed by old patterns of thought that can only be solved by new patterns of thought.  In order for the old patterns of thought thinker to be helped to form new patterns of thought, he must be accompanied by the new patterns of thought thinker to develop the capability to adopt new patterns of thought.  In other words, in order to really learn, people need to be accompanied by those who have more experience.  Such an exercise is far beyond the scope of any article and requires a completely different venue – namely the coaching relationship.  More about capacity-building and accompaniment later.

    For now, suffice it to say that the point of having a Definition of Done that is always changing is to allow for kaizen – the Definition of Done, therefore, like Standard Work, is only a baseline from which we constantly change for the better.  In other words, the Definition of Done is the record of what we are actually doing now. It allows us to be absolutely confident that we know as much as possilbe about what we are actual doing now so that we can make real, concrete, and confident decisions about actual improvements to our work.

    Actually doing the Definition of Done, as Ohno tells us is simple:  “See what is happening on the gemba [shop floor] and write it down.”  For many of us though, this simplicity is deceptive in that it is actually often very difficult – both the seeing and the writing.

    The ability to see what is actually going on is clearly vital to the capability of defining done.  It is valuable, therefore, to examine more closely the sense of sight:

    We have physical eyes that see.  What do our eyes see?  Light.  Is this what Ohno is talking about when he says “see what’s going on” – literally seeing light – or is he talking about a different kind of sight?  Clearly, what he is talking about is what we might call true sight, or the ability to see the truth.  We can think of truth, therefore as being like light.

    Is it our physical sight that sees the light of truth?  This, of course, is impossible since our physical eyes only see physical light.  So what is the sense in us that allows us to see the light of truth – in other words, what is true sight?   Some may say that it is our sense of justice.  One must have a strong, developed sense of justice in order perceive truth, especially in environments like software development in which the truth can be easily hidden.

    Writing down the Definition of Done with accuracy and clarity requires us to be both truthful and precise.  This is very difficult to do well in our present environments of opacity, defined roles, command and control management, fear of failure and general distrust.

    Clearly, we can see now that the Definition of Done, challenging to understand in its subtlety as a concept, is far more difficult to apply effectively in reality and therefore fully realize its value in practice.

    The concept that allows for the value of the Definition of Done to be realized is the concept of expanding the Definition of Done.  Expanding the Definition of Done in Scrum and Agile is the equivalent of kaizen in Lean Manufacturing.  In order to expand the Definition of Done, the actual Definition of Done needs to be well understood.  In other words,  “Where there is no Standard there can be no Kaizen.”

    Ohno says:

    “When creating Standard Work, it will be difficult to establish a standard if you are trying to achieve ‘the best way.’  This is a big mistake.  Document exactly what you are doing now.  If you make it better than it is now, it is kaizen.  If not, and you establish the best possible way, the motivation for kaizen will be gone.”

    This brings us back to the initial problem created by our old patterns of thought around our understanding of the Definition of Done – namely the misconception that at least some of the Definition of Done must be dictated by management in order to have consistency across teams working on the same large project.  The solution to this problem is challenging yet simple:  It’s irrelevant.  An organization is a living, breathing entity.  When management makes room for kaizen by not dictating standards, kaizen has more power to pollinate the entire organization and transform the way people think and work than imposed standards could ever begin to hope for.  Dictating standards, in other words, is limiting while kaizen harnesses the creativity of all.

    Again, Ohno says:

    “We need to use the words ‘you [the worker] made [the standard]’ as in ‘follow the decisions you made,’  When we say ‘they were made’ [for you] people feel like it was forced upon them.  When a decision is made, we need to ask who made the decision.  Since you also have the authority to decide, if you decide, you must at least follow your decision, and then this will not be forced upon you at all.

    “But in the beginning, you must perform the Standard Work, and as you do, you should find things you don’t like, and you will think of one kaizen idea after another.  Then you should implement these ideas right away, and make this the new standard.”

    Changing our patterns of thought requires creativity, but who’s creativity?

    Ohno:

    “Years ago, I made them hang the standard work documents on the shop floor.  After a year I said to a team leader, ‘The color of the paper has changed, which means you have been doing it the same way, so you have been a salary thief for the last year.’  I said ‘What do you come to work to do each day?  If you are observing every day you ought to be finding things you don’t like, and rewriting the standard immediately.  Even if the document hanging there is from last month, this is wrong.’

    “At Toyota in the beginning we had the team leaders write down the dates on the standard work sheets when they hung them.  This gave me a good reason to scold the team leaders, saying ‘Have you been goofing off all month?’

    “If it takes one or two months to create these documents, this is nonsense.”

    People on the shop floor or the Scrum teams need to be given the freedom and authority to figure out how to do their work better and change the standards of their work as they learn.  Ohno was really first and foremost a master coach who knew how to accompany people to develop their capabilities to perceive truth and generate and apply their own knowledge and creative solutions to challenging problems.

    Gary Hamel, in his article “Management Innovation” in the February 2006 edition of the Harvard Business Review, wrote:

    “Only after American carmakers had exhausted every other explanation for Toyota’s success- an undervalued yen, a docile workforce, Japanese culture, superior automation- were they finally able to admit that Toyota’s real advantage was its ability to harness the intellect of ‘ordinary’ employees.”

    In Scrum, the Team itself defines Done by what it actually gets done.  The ScrumMaster removes obstacles so that the Team can expand its Definition of Done (kaizen).  Scrum assumes that all Team members are dedicated to expanding the Team’s Definition of Done from Sprint to Sprint and that the Team will achieve this as long as organizational obstacles (such as managerial control fetish) are not impeding it from doing so.  When a Team is empowered in this way to expand its own Definition of Done (as well as empowered in other ways, according to the rules of Scrum), it will have the space it needs in order to grow into a hyper-productive Team.  That is to say that no one outside of the Team (i.e. management) dictates any part of the Team’s Definition of Done (a common management practice that results in kai-aku).  The Definition of Done is one ingredient in the remedy for curing our culture’s leadership disease – the failure to learn.

    “…your failure is an internal disease…You firmly believe that sound management means executives on the one side and workers on the other, on the one side men who think and on the other side men who only work.”  -Konusuke Matsushita

    (Shameless Plug: we offer excellent Certified ScrumMaster Training and in it we discuss the Definition of “Done” in the context of people’s actual problems.)

    Share and Enjoy:
    • TwitThis
    • LinkedIn
    • Digg
    • Technorati
    • del.icio.us
    • Propeller
    • StumbleUpon
    • Reddit
    • Fark
    • Slashdot
    • Blogsvine
    • Google Bookmarks
    • Furl
    • Facebook
    • BlinkList
    • YahooMyWeb

    The Decline and Fall of Agile and How Scrum Makes it Hurt More

    Sunday, November 16th, 2008

    James Shore wrote a great post about the problems he is seeing with agile adoptions that start with Scrum called the Decline and Fall of Agile.  Please please please (pretty please) read it before you read what I am about to write here!  I agree with what James is saying 100%.

    Now, let’s hear the truth:

    Scrum is really really hard!  Doing Scrum well is like quitting a heavy, long addiction (I think).  Don’t ever make the mistake that because Scrum is simple (lack of complexity) that it is somehow therefore easy (lack of effort).

    Doing Scrum properly takes:

    sacrifice – sacrifice of our ways of thinking, our habits, our comfort

    wisdom – wisdom to see the small improvements while struggling with the humongeous ones

    and most importantly,

    truthfulness – honesty to see and say the truth, integrity to act on the truth, detachment to avoid believing in what you want instead of what is real, courage to continue even when things aren’t perfect or easy

    Scrum depends heavily on commitment both at the small scale of an individual committing to a small piece of work, and at the large scale of an organization committing to real deep cultural change.  Without that entire spectrum of commitment, it is unlikely that adopting Scrum will be anything but the latest fad imposed by management or done stealthily by staff.

    But Scrum isn’t the only “agile” method.  As James points out, the engineering practices of Extreme Programming such as pair programming, test driven development, continuous integration, evolutionary design and refactoring are all critical.  Do they have to be done and perfected first?  No.  But eventually, if you are using Scrum to build software (not everyone is), they do have to be done.

    As a Certified Scrum Trainer, I have always emphasized how Scrum is hard, and how being a ScrumMaster is very very very hard.  This is why my training class is three days instead of two.  This is why I don’t encourage anyone to come to it, only people who will be ScrumMasters.  This is why after the first day of my course, most students are actually feeling quite discouraged!!!  It takes three days minimum for people to understand and process the incredible shift in mental model.  And of course, even after three days, it is oh so easy to revert back to our normal thinking habits.

    So what should people do?  Do Scrum by the book.  Yes that means putting a whole team in a single room.  Yes it means that you have to really remove obstacles, and fast!  Yes that means that your teams actually have to be cross functional (and not just in the weak sense of multi-skilled developers).  Yes that means that it – will – take – a – long – time – to – get – it – right!!!!

    And please, it is so worth getting help beyond just the training!  If you think that I’m just trying to promote my own coaching services, please go check out:

    www.ccpace.com

    www.rallydev.com

    www.outformations.com

    www.lithespeed.com

    www.mountaingoatsoftware.com

    www.controlchaos.com

    www.bigvisible.com

    www.kittyhawkconsulting.com

    They all have great coaches and I would absolutely way rather see you succeed than believe that I am just trying to promote my own business.

    Share and Enjoy:
    • TwitThis
    • LinkedIn
    • Digg
    • Technorati
    • del.icio.us
    • Propeller
    • StumbleUpon
    • Reddit
    • Fark
    • Slashdot
    • Blogsvine
    • Google Bookmarks
    • Furl
    • Facebook
    • BlinkList
    • YahooMyWeb

    The Importance of Questions

    Tuesday, October 28th, 2008

    I’m currently doing some coaching work with Regina, a new project manager working with a small team of web developers at a community development organization in Toronto.  We had our first session last week. Regina was having trouble getting started on a particular project and I shared with her some of the Agile methods of creating a prioritized Cycle Plan, breaking it down into small tasks, etc.

    Regina seems to be finding Agile methods helpful in general, but there was a special kind of interaction that we had around removing an obstacle that was particularly interesting for me.  It had to do with an email she received from Peter, a developer working on one of the websites she’s managing. Regina shared a concern that she didn’t know some of the technical terms Peter was using.  So I had her read through the email and form questions around the points she wasn’t clear about – i.e., “what are buttons?” and I wrote them down as she was speaking.

    I then suggested that she compose a reply email containing the same set of questions.  Regina’s eyes opened wide and she exclaimed, “Oh yeah – that’s so obvious!”  I went on to mention that another option would be to go and do some research on her own but that there were some valuable advantages in asking Peter directly, particularly in terms of team-building, that may not be as immediately apparent as asking the questions solely for the purpose of having them answered.  Here are a few:

    First, it’s a way forRegina to remind Peter that she does not have a technical background and that he should not assume that she is familiar with web-lingo.  Second, it also reminds him that she is a different person from the last manager he was working with and subtly reinforces that it’s important that they get to know each other as two individual human beings and learn to work together effectively.  Third, and perhaps most importantly, it gives Peter an opportunity to help someone else on the team learn something new, and by doing so, contribute to the culture of learning on the team.  Fourth, and perhaps most obviously, it promotes open lines of clear communication on the team.

    (Of course, if the team was colocated, which it is not, lack of communication would be much less of an obstacle!)

    Asking questions in the interest of learning makes it visible to others that you don’t know everything.  For some people, this presents a dilemma.  What makes it a dilemma is that asking meaningful questions is something that many people aren’t able to do well.  The ability to ask meaningful questions is a learnable skill requiring the capabilities of truthfulness, humility and courage.  Such capabilities – let’s call them moral capabilities – can themselves be developed through conscious, focused effort.

    Someone in the position of a newly hired manager, or a veteran manager with a new team, who lacks these capabilities may feel that it is important to present to a team a persona of all-knowingness.  But, of course, this is false and the truth of one’s degree of knowledge and capability, or lack thereof, soon becomes apparent anyway.  Clearly, this person needs to do some honest hard work to develop some humility, but truthfulness and courage are still often major factors.

    Or maybe you’re the kind of person (like Regina) who just doesn’t want to bother anyone.  In this case, humility is not necessarily lacking, but truthfulness – and perhaps most of all courage – may need some attention.  Concepts around moral capabilities deserve much more elaboration, but for the sake of brevity, I’ll leave it at that.

    To sum it up, if you are open and clear in the way you ask questions, people will tend to appreciate it and will trust you more in the end.  Moreover, it can have a transformative effect on the environment of the team.  When your team members realize that you are not afraid to ask questions and be truthful about your lack of knowledge in a certain area, it will encourage them to be more truthful about their own capabilities.  Not to mention that most people feel good when they are able to help others.  When your team members feel safe to ask for help and free to help each other, it is empowering for everyone.

    Asking meaningful questions, therefore, is an essential aspect of learning together, and nothing is a more powerful contributor to the success of an organization than a team that learns as a team.

    Share and Enjoy:
    • TwitThis
    • LinkedIn
    • Digg
    • Technorati
    • del.icio.us
    • Propeller
    • StumbleUpon
    • Reddit
    • Fark
    • Slashdot
    • Blogsvine
    • Google Bookmarks
    • Furl
    • Facebook
    • BlinkList
    • YahooMyWeb