Link: Slashdot on Mob Programming

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

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.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Design Debt & UX Debt is Technical Debt

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

Hey! Let’s all work together, please.

Technical Debt is a term which captures sloppy code, unmaintainable architecture, clumsy user experience, cluttered visual layout, bloated feature-sets, etc.  My stance is that the term, Technical Debt, includes all the problems which occur when people defer professional discipline — regarding any/every technical practice such as product management, visual and UX design, or code.

I assert that the change we need to catalyze in the business community is larger than any one discipline and I am worried that I have seen an increase in blog articles in recent years about concepts like “Design Debt”, “UX Debt”, “Experience Debt” — these articles unfortunately are not helping and have served only to divide the community. They are divisive, not because we shouldn’t be discussing the discreet facets in which Technical Debt can manifest, but because authors often take a decidedly combative approach in their writing.  Take these phrases for example:

  • “Product Design Debt Versus Technical Debt” written by Andrew Chen
  • “User Experience Debt: Technical debt is only half the battle” written by Clinton Christian
  • “Design debt is more dangerous because…” written by James Engwall.

I agree with Andrew Chen that Product Design Debt is a problem — I just don’t like that he chose to impose a dichotomy where there is none.  Why must he argue one “versus” another?  Clinton Christian has implied that we’re in a “battle”.  James Engwall has compared the “danger” of Design Debt relative to Technical Debt.  These words are damaging, I argue, because they divert attention to symptoms and away from root causes.

The root cause of Technical Debt is that people forget this simple principle of the Agile Manifesto: “Continuous attention to technical excellence and good design enhances agility.”

The root solution to Technical Debt — all of its forms — is to help business leaders realize there is a difference between “incremental” development and “iterative” development so they may understand the ROI of refactoring.  No technical expert should ever have to justify the business case for feature-pruning, refreshing a user interface, refactoring code, prioritizing defects.  Every business leader should trust that their technical staff are disciplined and excellent.

Yes, please blog about UX Debt and Product Development Debt, etc.  But please do so in a way that encourages cohesion and unity within the Product Development community.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

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

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

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. (™)


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

When the team says, “we need detailed requirements before we can estimate”…

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

The next time the team says “we can’t estimate without better requirements” what they actually mean is, “this is crazy, but hey…if you think you can accurately predict all the exact requirements and you can guarantee that nobody in this company will change their minds about those requirements between this moment and forever, then we’ll give you an estimate to hang your hat/noose on.”

Every group responsible for the creation and delivery of software (or any complex/creative product for that matter) will experience dissonance between the need to plan and the need to obey the laws of nature which prevent us from travelling through time and future-telling.  Business leaders have to finance the development of product; creative and technical leaders have to solve complex problems amidst dynamic, unpredictable, circumstances.  These conditions manifest as a dichotomy which is difficult to mediate (at best) and/or downright toxic (at worst).

On one hand, a common sentiment among project managers is: “The problem I have with the release planning stage is that without clear requirements, the developers don’t like to give estimates, even with story points.”

On the other hand, a common sentiment among developers is: “Stakeholders don’t understand what they’re asking for, if they knew the complexity of our technology they wouldn’t be asking those questions.”

If developers don’t like to provide estimates, it is likely because others in the organization have used their estimates as though they are accurate predictions of future. Thus, when said estimates turn out to be inaccurate they are used as punitive metrics in conversations about “commitment” and “velocity” and “accountability”.

Point of order: NOBODY CAN PREDICT THE FUTURE.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Nexus Reifies

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

Nexus Scrum

I had the privilege of attending Scrum.org‘s 2-day seminar on Scaled Professional Scrum. The Nexusa connection or series of connections linking two or more things (direct translation from Latin a binding together), is the recommended scaling framework. The purpose of the Nexus is to manage dependencies between 3-9 Scrum Teams towards “reification”, to make an abstract idea real or concrete. This is ensured mostly through a single Product Owner, single Product Backlog, integrated (Nexus) Sprint Planning, Review and Retrospective and the addition of a Nexus Integration Team whose membership is made up mostly of Scrum team members internal to the Nexus, but often also includes other support personnel. The structure is very similar to LeSS, but perhaps even less prescriptive and is certainly much less prescriptive than SAFe. This is probably my favourite thing about the Nexus – the fact that it has just enough structure to be a model for scaling Scrum, but is light and flexible enough to accommodate all of the nuances that “just depend” on your situation. Like the other two above-mentioned scaling models, it places emphasis on the need for strong technical practices, continuous integration and the synchronization of events to facilitate integration. There is flexibility around synchronization, in that if the Nexus Sprint is 4 weeks in duration and teams within the Nexus want to do 2 or even 1 week Sprints, the model accommodates – as long as all of the teams’ work is combined into a fully integrated (reified) increment of potentially shippable product by the end of the Nexus Sprint.

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Request for Feedback on Agile Advice Book

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

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!


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Agile Manifesto – Essay 3: Working Software over Comprehensive Documentation

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

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“.

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail