All posts by Mishkin Berteig

Mishkin Berteig is a Baha'i, a father of four, a husband and an experienced Agile consultant and trainer. Mishkin is a Certified Scrum Trainer (CST) with the Scrum Alliance, a certified Master of OpenAgile with the OpenAgile Centre for Learning and a certified SAFe Program Consultant (SPC) with the Scaled Agile Academy. Mishkin has a technical background including a B.Sc. in Computer Science and worked as a Chief Architect reporting to the CIO of Charles Schwab, but gave it up to be more Agile.

Video: The Myths of Scrum – Scrum is for IT Projects

Subscribe to our BERTEIG / WorldMindware YouTube channel – we have over 20 more videos planned on the Myths of Scrum.

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

Pitfall of Scrum: Assigning Tasks

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

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

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

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

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

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

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

What If One Person Isn’t Working?

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

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

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

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

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

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

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

Why Self-Organize – Why Is Assigning Tasks Bad?

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

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

The ScrumMaster and Assigning Tasks

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

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

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

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

Video: Sprint Zero is Not Part of Scrum

Find out why Sprint Zero is a bad idea, and what you can do instead!

More Scrum and Agile videos to come!  Please subscribe to our WorldMindware channel.

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

New Video: Myths of Scrum – A Public Retrospective

Although subtle, having a public retrospective can do terrible damage to a Scrum team.  In this video I explain what I mean by “public”, why it is so bad, and what you should do instead.  This is part of a video series on the Myths of Scrum that is meant to respond to some of the most common mis-information (myths) about Scrum and Scrum practices.  I will follow-up this video in several weeks with a written article complimentary to this video.  Feel free to let me know in the comments if you have any topics that you would like me to cover in my video series!

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

Pitfall of Scrum: Problem-Solving in the Daily Scrum

The Daily Scrum should not be used to find solutions to problems (obstacles, impediments) raised. Instead, keep the meeting very short and have those problem-solving conversations afterwards with only those who are interested. The ScrumMaster facilitates this meeting to keep it on track. The Daily Scrum is timeboxed to a maximum of 15 minutes, but often should be even less. With a good physical task board, a Daily Scrum can often be done in less than a minute simply by each team member pointing at the pieces of work they are working on.

From the Scrum Guide:

The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.

In other words, don’t have those discussions during the Daily Scrum! The Daily Scrum is essential to creating transparency and implementing the Scrum value of Openness. The three questions of the Daily Scrum are effectively:

  1. What did I do since the last time we checked in as a team?
  2. What am I planning to do before the next check in time?
  3. What impediments, if any, are preventing us from getting our work done?

Each member of the team takes a turn and answers those three questions. This doesn’t have to be completely stilted, but it should be Focused (another value of Scrum) and efficient so that the need for other meetings is minimized. Accomplishing this takes some practice. The ScrumMaster helps the team to keep the timebox, but at first, a team might have challenges with this.

Struggling with the Daily Scrum

There are a some common reasons that a team might struggle with wanting to problem solve in the Daily Scrum:

  • One team member doesn’t know what to do next and it devolves into re-planning right there and then. A quick suggestion or two is probably fine, but it is a very steep slippery slope. A team can easily get into the habit of always doing this! The ScrumMaster needs to be vigilant about recommending that the discussion be taken up after the Daily Scrum is concluded in order to avoid this pitfall. This suggestion will be common when a team is first starting out.
  • One person mentions an impediment that someone else knows how to solve… and a third person has a different idea of solving it. In this situation it is much better for interested team members to just simply indicate “I have an idea for that,” and let the Daily Scrum continue. Then after the Daily Scrum those people have a quick discussion. This avoids wasting the time of everyone on the team with something that is only interesting to a few.
  • An individual doesn’t seem to have anything to report and other team members try to elicit more information. This should really be something that the ScrumMaster or the team’s coach should take up with the individual. It may be that there is an impediment that the person is uncomfortable sharing openly with the whole team. There is a subtle pitfall that may be revealed here: that the team does not have the safety to self-organize.
  • Disagreement about what to do next. This type of problem is the hardest to deal with because many people will feel that disagreements need to be resolved before any action can be taken. A good ScrumMaster will actually encourage competing ideas to be attempted. Learn by doing instead of by argument and analysis. This is the fundamental shift in culture that Scrum is attempting to put in place: an empirical approach to work rather than a defined approach.

Just beware: yet another pitfall (although not common) is to decide that the Daily Scrum shouldn’t be daily because it is taking so long. Unfortunately, making this change will often just make the meetings even longer until they devolve back into weekly status meetings reporting to the team lead!!! Remember that it’s not Scrum anymore if your team doesn’t meet together daily.

Ultimately, if a team is struggling with the Daily Scrum in any way, this is a valid topic for discussion in the Sprint Retrospective.

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

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

Link: Meeting Check-Ins

Very nice article called Why I Always Start a Meeting with a Check-In.  From the article by Ted Lord, senior partner, The Giving Practice:

The greatest benefit of working in a group is our diversity of viewpoints and approaches; groups hobble themselves when they don’t continually give attention to creating a container of trust and shared identity that invites truth-telling, hard questions, and the outlier ideas that can lead to innovation

One antidote to over-designed collaboration is the check-in.

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

New Video: Myths of Scrum – ScrumMaster Assigns Tasks

In a few weeks, I will be posting a more detailed written follow-up to this video.  This is one of the most damaging and most common myths (or pitfalls) that ScrumMasters fall into….

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

Pitfall of Scrum: Focus on Scrum Tools

Many organizations try to find an electronic tool to help them manage the Scrum Process… before they even know how to do Scrum well! Use team rooms and manual and paper-based tracking for early Scrum use since it is easiest to get started. Finding a Scrum tool is usually just an obstacle to getting started.

The culture of most technology companies is to solve problems with technology. Sometimes this is good. However, it can go way overboard. Two large organizations have attempted to “go Agile” but at the same time have also attempted to “go remote”: to have everyone using electronic Scrum tools from home to work “together”. The problem with electronic Scrum tools is three-fold. They

  1. prevent the sharing of information and knowledge,
  2. reduce the fidelity of information and knowledge shared, and
  3. delay the transfer of information and knowledge.

Scrum Tools Prevent Information Sharing

Imagine you are sitting at your desk in a cubicle in an office. You have a question. It’s a simple question and you know who probably has the answer, but you also know that you can probably get away without knowing the answer. It’s non-critical. So, you think about searching the company directory for the person’s phone number and calling them up. Then you imagine having to leave a voice mail. And then you decide not to bother.

The tools have created a barrier to communicating. Information and knowledge are not shared.

Now imagine that the person who has the answer is sitting literally right next to you. You don’t have to bother with looking up their number nor actually using a phone to call. Instead, you simply speak up in a pretty normal tone of voice and ask your question. You might not even turn to look at them. And they answer.

Scrum tools are no different from these other examples of tools.  It takes much more energy and hassle to update an electronic tool with relevant, concise information… particularly if you aren’t good with writing text.  Even the very best Scrum tools should only be used for certain limited contexts.

As the Agile Manifesto says: “The most effective means of conveying information to and within a team is face-to-face communication.”

Scrum Tools Reduce Information Fidelity

How many times have you experienced this? You send an email and the recipient completely misunderstands you or takes it the wrong way. You are on a conference call and everyone leaves the call with a completely different concept of what the conversation was about. You read some documentation and discover that the documentation is out of date or downright incorrect. You are using video conferencing and its impossible to have an important side conversation with someone so you resort to trying to send text messages which don’t arrive on time to be relevant. You put a transcript of a phone call in your backlog tracking tool but you make a typo that changes the meaning.

The tools have reduced the fidelity of the communication. Information and knowledge are incorrect or limited.

Again, think about the difference between using all these tools and what the same scenarios would be like if you were sitting right beside the right people.  If you use Scrum tools such as Jira, Rally* or any of the others, you will have experienced this problem.  The information that gets forced into the tools is a sad shadow of the full information that could or should be shared.

As the Agile Manifesto says: “we have come to value: individuals and interactions over processes and tools.”

Scrum Tools Delay Information Transfer

Even if a person uses a tool and even if it is at the right level of fidelity for the information or knowledge to be communicated, it is still common that electronic tools delay the transfer of that information. This is obvious in the case of asynchronous tools such as email, text messages, voice mail, document repositories, content management systems, and version control. The delay in transfer is sometimes acceptable, but often it causes problems. Suppose you take the transcript of a conversation with a user and add it into your backlog tracking tool as a note. The Scrum Team works on the backlog item but fails to see the note until after they have gone in the wrong direction. You assumed they would see it (you put it in there), but they assumed that you would tell them more directly about anything important. Whoops. Now the team has to go back and change a bunch of stuff.

The Scrum tools have delayed the communication. Information and knowledge are being passed along, but not in a timely manner.

For the third time, think about how these delays would be avoided if everyone was in a room together having those direct, timely conversations.

As the Agile Manifesto says: “Business people and developers must work together daily throughout the project.”

Alternatives to Scrum Tools

Working in a team room with all the members of the Scrum Team present is the most effective means of improving communication. There are many photos available of good team rooms. To maximize communication, have everyone facing each other boardroom-style. Provide spacious walls and large whiteboards. Close the room off from other people in the organization. Provide natural light to keep people happy. And make sure that everyone in the room is working on the same thing! Using Scrum tools to replace a team room is a common Scrum pitfall.

Scrum Tools - Labelled Team Room Photo

The most common approach to helping a team track and report its work is to use a physical “Kanban” board. This is usually done on a wall in which space is divided into columns representing (at least) the steps of “to do”, “in progress” and “done”. On the board, all the work is represented as note cards each with a separate piece of work. The note cards are moved by the people who do the work. The board therefore represents the current state of all the work in an easy-to-interpret visual way. Using a tool to replace a task board is another variant of this common Scrum pitfall.

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

* Disclaimer: BERTEIG is a partner with a tool vendor: Version One.

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

Link: About Development Managers

My colleague and friend Mike Caspar has posted another insightful article on his blog: Do not create unnecessary fear and animosity with Development Managers.  From the article:

As teams grow, they build confidence and seem to become self-contained, and almost insular to some. This is normal and is not a sign of dysfunction. This simply indicates that the team is starting to have self identity. They are starting to act as a team. This is a good sign…. As the teams become more effective, the Development Manager feels more loss.

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

Pitfall of Scrum: Excessive Preparation/Planning

Regular big up-front planning is not necessary with Scrum. Instead, a team can just get started and use constant feedback in the Sprint Review to adjust it’s plans. Even the Product Backlog can be created after the first Sprint has started. All that is really necessary to get started is a Scrum Team, a product vision, and a decision on Sprint length. In this extreme case, the Scrum Team itself would decide what to build in its first Sprint and use the time of the Sprint to also prepare some initial Product Backlog Items. Then, the first Sprint Review would allow stakeholders to provide feedback and further develop the Product Backlog. The empirical nature of Scrum could even allow the Product Owner to emerge from the business stakeholders, rather than being assigned to the team right from the start.

Starting a Sprint without a Product Backlog is not easy, but it can be done. The team has to know at least a little about the business, and there should be some (possibly informal) project or product charter that they are aware of. The team uses this super basic information and decides on their own what to build in their first Sprint. Again, the focus should be on getting something that can be demoed (and potentially shippable). The team is likely to build some good stuff and some things that are completely wrong… but the point is to get the Inspect and Adapt cycle started as quickly as possible. Which means of course that they need to have stakeholders (customers, users) actually attend the demo at the end of the Sprint. The Product Owner may or may not even be involved in this first Sprint.

One important reason this is sometimes a good approach is the culture of “analysis paralysis” that exists in some organizations. In this situation, an organization is unable to do anything because they are so concerned about getting things right. Scrum is a framework for inspect and adapt and that can (and does) include the Product Backlog. Is it better for a team to sit idle while someone tries to do sufficient preparation? Or is it better to get started and inspect and adapt? This is actually a philosophical question (as well as a practical question). The mindset and philosophy of the Agile Manifesto and Scrum is that trying to produce valuable software is more important that documentation… that individuals and how they work together is more important than rigidly following a process or tool. I will agree that in many cases it is acceptable to do some up-front work, but it should be minimized, particularly when it is preventing people from starting to deliver value. The case of a team getting started without a product backlog is rare… but it can be a great way for a team to help an organization overcome analysis paralysis.

The Agile Manifesto is very clear: “The BEST architectures, requirements and designs emerge out of self-organizing teams.” [Emphasis added.]

Hugely memorable for me is the story that Ken Schwaber told in the CSM course that I took from him in 2003.  This is a paraphrase of that story:

I [Ken Schwaber] was talking to the CIO of a large IT organization.  The CIO told me that his projects last twelve to eighteen months and at the end, he doesn’t get what he needs.  I told him, “Scrum can give you what you don’t need in a month.”

I experienced this myself in a profound way just a couple years into my career as an Agile coach and trainer.  I was working with a department of a large technology organization.  They had over one hundred people who had been working on Agile pilot projects.  The department was responsible for a major product and executive management had approved a complete re-write.  The product managers and Product Owners had done a lot of work to prepare a product backlog (about 400 items!) that represented all the existing functionality of the product that needed to be re-written.  But, the big question, “what new technology platform do we use for the re-write?” had not yet been resolved.  The small team of architects were tasked with making this decision.  But they got stuck.  They got stuck for three months.  Finally, the director of the department, who had learned to trust my advice in other circumstances, asked me, “does Scrum have any techniques for making these kind of architectural decisions?”

I said, “yes, but you probably won’t like what Scrum recommends!”

She said, “actually, we’re pretty desperate.  I’ve got over a hundred people effectively sitting idle for the last three months.  What does Scrum recommend?”

“Just start.  Let the teams figure out the platform as they try to implement functionality.”

She thought for a few seconds.  Finally she said, “okay.  Come by this Monday and help me launch our first Sprint.”

The amazing thing was that the teams didn’t lynch me when on Monday she announced that “our Agile consultant says we don’t need to know our platform in order to get started.”

The first Sprint (two weeks long) was pretty chaotic.  But, with some coaching and active support of management, they actually delivered a working increment of their product.  And decided on the platform to use for the rest of the two-year project.

You must trust your team.

If your organization is spending more than a few days preparing for the start of a project, it is probably suffering from this pitfall.  This is the source of great waste and lost opportunity.  Use Scrum to rapidly converge on the correct solutions to your business problems instead of wasting person-years of time on analysis and planning.  We can help with training and coaching to give you the tools to start fast using Scrum and to fix your Scrum implementation.

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

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

Link: Slashdot on Mob Programming

Slashdot has a post on mob programming that, as usual, has brought out the poorly socialized extreme introverts and their invective. There are always interesting and insightful comments as well.  I recommend checking it out.  The post links to some studies about mob programming that are also interesting.

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

Announcement: BERTEIG partners with Version One and Scaled Agile Inc.

The past month has been busy!  BERTEIG has officially partnered with both Version One and Scaled Agile Inc.  As BERTEIG grows, our partnerships provide great new resources for our clients.

These partnerships are an outgrowth of our re-branding strategy which saw the launch of our new logo and website early last month.  In the near future we will be announcing more partnerships and relationships to further support our customers and clients.

About VersionOne

VersionOne is a recognized leader and visionary in agile lifecycle management software and services. Our mission is to help companies envision and deliver great software. Since 2002, companies such as Adobe, Capital One, and Oracle have turned to VersionOne. Today, more than 50,000 teams at 1,000 companies, including 37 of the Fortune 100, use our solutions to help them scale their agile initiatives faster, easier and smarter. Whether a small team just starting out with agile or a global enterprise scaling agile, VersionOne customers get the best solutions in the industry backed by the pioneers in agile lifecycle management.

About Scaled Agile Inc and SAFe

Scaled Agile, Inc.’s mission is to help enterprises achieve the capabilities, culture and business benefits that successful implementation of scaled Lean and Agile practices can provide. To achieve this, Scaled Agile provides consulting, training, certification and process tooling based on the Scaled Agile Framework, a proven, publicly-facing knowledge base of effective practices for Lean | Agile adoption at enterprise scale. Visit www.ScaledAgile.com for more details.

The Scaled Agile Framework is a proven, publicly-accessible knowledge base for implementing agile practices at enterprise scale, consisting of approximately 300 pages of guidance. Its primary interface is the “Big Picture” graphic which highlights the individual roles, teams, activities and artefacts necessary to scale agile from the team, to teams of teams, to the enterprise level. It has been successfully applied in programs ranging from only 50-100 people, to enterprises employing thousands of software developers. For more information on the Scaled Agile Framework, visit: www.scaledagileframework.com.

About BERTEIG

BERTEIG is the leading provider of Agile training, coaching and consulting services in the Toronto area.  Agile Advice, World Mindware, The Real Agility Program, The Scrum Team Assessment and OpenAgile are all BERTEIG initiatives and services.  BERTEIG has helped organizations achieve dramatic improvements in time-to-market, near-perfect quality, and 400% boost in overall productivity while at the same time helping people learn to love their work again.  BERTEIG is transforming people, process and culture through the power of Real Agility. (™)

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

Request for Feedback on Agile Advice Book

Agile Advice Book - coverMy Agile Advice book has been out for a little more than 4 months.  I’m extremely happy about the fact that over 25 people have purchased it so far without me doing any active promotion.  If any of my blog readers have purchased it, I am looking for feedback – please leave comments below.  (And, of course, if you haven’t purchased the book it’s only $2 on lulu.com and iBookstore.)

I am preparing the next release of the book: version 1.1.  It will include many minor changes and some new content, but I have only received a bit of feedback so far and I would greatly appreciate more.  Again, the best forum for feedback is here – feel free to be critical – I really want to make this better!

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 3: Working Software over Comprehensive Documentation

How much documentation does it take to run a project with ten people working for six months?  For some organizations it takes way too much:

Photo of heavy documentation for software project

This binder (about 3 or 4 inches thick) is all the documentation associated with such a project.  In looking carefully at the project, creating the documentation took far more time than the time spent on designing, writing and testing the software.  Yet, the documentation does not produce any value.  Only the software produces value.  The Agile Manifesto, asks us to focus on the outcome (working software) and to make tradeoffs to minimize the means (comprehensive documentation).

The Agile Manifesto asks us to challenge our assumptions about documentation.  In many work environments, documentation is an attempt to address some interesting and important needs:

  • Knowledge sharing among stakeholders and the people working on a project.
  • Knowledge sharing across time as people come in and out of a project.
  • Verification and traceability for contracts or other compliance needs.
  • Decision-making and analysis for business and technical problems.
  • Management oversight and control.
  • Various aspects of individual accountability.

Documentation is usually heavier (more comprehensive) the more the following circumstances exist in an organization:

  • Geographical distribution of people.
  • Lack of trust between people, departments or organizations.
  • Regulated work environments.
  • Depth of management hierarchy.
  • Number of people directly and indirectly involved.
  • Knowledge and skill sets highly segregated between people.
  • Culture of respect for written texts.

Working Software

What if the software itself could address the needs that often documentation is used to address?  Let’s look at them in turn:

  • Knowledge sharing among stakeholders and the people working on a project.
    If the software is functional at all stages, as supported by Agile methods such as Scrum and Extreme Programming, then the software becomes an effective representation of the knowledge of all the people who have participated in building it.
  • Knowledge sharing across time as people come in and out of a project.
    Software that is technically excellent is often easier to understand for people who are new to it.  For example, excellence in user experience and design means new users can get up to speed on software faster.  Use of good design patterns and automated testing allows new developers to understand existing software easily.
  • Verification and traceability for contracts or other compliance needs.
    Test-driven development (code) and specification by example (scripting and code) are forms of traceable, executable documentation that easily stay in-sync with the underlying software system.
  • Decision-making and analysis for business and technical problems.
    In particular, diagrams can help a great deal here.  However, electronic tools for creating such diagrams can be slow and awkward.  Consider the practice of Agile Modelling (basically using a whiteboard and taking photos) as a good alternative to precise technical diagramming if you are doing problem-solving.
  • Management oversight and control.
    Reports and metrics drive much of the traditional documentation in an organization.  Simplifying reports and metrics often leads to a clearer picture of what is going on, reduces the opportunities to “game” the system, and always results in lower levels of documentation.  As well, some reports and metrics can be generated 100% through automated means.  All that said, the fundamental premise in the Agile manifesto is that management should base decisions on what is actually built – the “Working software” by looking at it and using it.
  • Various aspects of individual accountability.
    If you really need this, a good version control system can give you the information for this.  Sign-offs and other types of accountability documentation are typically just waste that doesn’t actually help in process improvement.  Most people who are in high-compliance environments already have licenses and/or security clearances that provide this accountability.  If you software is working, however, then this isn’t even a concern as trust is built and bureaucracy can be reduced.

In my recent training programs as research for this article, I have surveyed over 100 people on one aspect of documentation – code documentation.  Every individual surveyed is either currently coding or has a coding background, and every single person had the same answer to a simple scenario question:

Imagine that you have just joined a new organization and you are about to start working as a software developer.  One of the existing team members comes up to you and introduces himself.  He has with him a piece of paper with a complicated-looking diagram and a full binder that looks to be holding about 250 pages.  He asks you, “you need to get up to speed quickly on our existing system – we’re starting you coding tomorrow – would you prefer to go over the architecture diagram with me or would you prefer to review the detailed specifications and design documents.” He indicates the one-page diagram and the binder respectively.  Which would you prefer?

(I’ve put up a Survey Monkey one-question survey: Code Documentation Preference to extend the reach of this question.  It should take you all of 60 seconds to do it.  I’ll post results when I write the next Agile Manifesto essay in a month or two.)

The fact that everyone answers the same way is interesting.  What is even more interesting to me is that if you think through this scenario, it is actually almost the worst-case scenario where you might want documentation for your developers.  That means that in “better” cases where documentation for developers may not be as urgent or necessary, then the approach of just going to talk with someone is a lot better.

Documentation and Maps

The problem with documentation is the same problem we have with maps: “the map is not the territory” (quote from the wisdom of my father, Garry Berteig).  We sometimes forget this simple idea.  When we look at, say, Google Maps, we always have in the back of our consciousness that the map is just a guide and it is not a guarantee.  We know that if we arrive at a place, we will see the richness of the real world, not the simplified lines and colours of a map.  We don’t consider maps as legally binding contracts (usually).  We use maps to orient ourselves… as we look around at our reality.  We can share directions using maps, but we don’t share purpose or problems with maps.  And finally, maps assume that physical reality is changing relatively slowly (even Google Maps).

Many times when we create documentation in organizations, however, we get confused about the map versus the territory.

Agility and Documentation

Of course, code is a funny thing: all code is documentation too.  The code is not the behaviour.  But in software, code (e.g. Java, ASM, Scheme, Prolog, Python, etc.) is as close as possible to the perfect map.  Software is (mostly) deterministic.  Software (mostly) doesn’t change itself.  Software (mostly) runs in a state absent from in-place human changes to that software.  Software (mostly) runs on a system (virtual or physical) that has stable characteristics.  The code we write is a map.  From this perspective, documentation becomes even less important if we have people that already understand the language(s)/platform(s) deeply.


This essay is a continuation of my series on the Agile Manifesto.  The previous two essays are “Value and Values” and “Individuals and Interactions over Processes and Tools“.

 

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