January 20, 2017

Self-Organizing Teams for the Rest of Us (Another Look)

—A comparison of definitions for self-organizing teams.

In Self-Organizing Teams for the Rest of Us, I shared Bertrand Meyer’s position on self-organizing teams. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team–highly accomplished self-organizing teams may not require a manager. Self-Organizing teams are self-managed or self-designing.¹

In TSP: Leading a Development Team, Watts S. Humphrey provides a look at self-directed teams.

Is there a difference between self-directed and self-organized teams? If there is, it’s that self-directed teams have leaders with a set of responsibilities that are broader than the team’s responsibilities. In Humphrey’s view, a leader motivates people to achieve goals and provides an environment where team members focus on results and accomplishments. A manager controls resources to produce results.

Self-directed teams exhibit the following characteristics.

A sense of membership and belonging.
Commitment to a common team goal.
Ownership of the process and the plan.
The skill to make a plan and the discipline to follow it.
A dedication to excellence.

A leader’s focus is to create an environment to support and sustain these characteristics. Theirs responsibility is to motivate, coach and drive team members to perform at the best of their abilities.

This notion of self-directed team is closer to the notion of team that I support in Self-Organizing Teams for the Rest of Us. What’s refreshing in Humphrey’s description of self-directed teams is that the role of a leader is made explicit.

What Meyer points out is the rhetoric around self-organizing teams describes what managers shouldn’t do. I agree this is unhelpful for people placed in the position of trying to build an Agile environment.

Agile!: The Good, the Hype and the Ugly by Bertrand Meyer My rating: 4 of 5 stars	TSP-Leading a Development Team by Watts S. Humphrey
View all my reviews

^{1. What Are Self-Organising Teams?.
↩}

December 28, 2016

Well-Written Scrum Stories

—The stuggle of writing good user stories in mixed environments.

I work in a domain where Stories in the sense of Well-Written Scrum Stories don't always work well. Think this is heresy? Read on.

My domain involves the construction of a system. Part of my team's responsibilities include writing software for business logic but it also includes writing software for control elements within the system. For example, we might be asked to integrate a new sensor into our application and that sensor might affect the user's work flow or we might integrate software in the support of mechanical elements (such as motors).

Stories for the sensor integration typically don't sit well with me. The reason for this is that I emphasize user value for my stories. In simple terms, my customers won't pay a sensor. They will pay for the utility provided by the work flow change that the sensor enables.

My emphasis on user value has worked well in other domains. I worked on the integration of Cilk Plus into LLVM. We were able to define stories that embodied user value. For example, one user story included the introduction of a for-loop supporting parallelism into the compiler and subsequent stories included the introduction of different stepping increments in the for-loop.

My current domain doesn't have that luxury. Or at least I haven't mastered this domain to that level.

The best description I've seen relating to my problem with stories in my domain comes from Bertrand Meyer. In Agile! The Good, the Hype and the Ugly, he describes how stories are not useful for describing situations with multiplicative complexity. That is things where all of the key elements of a system must be taken into account at the beginning.

So I live in a world where I use user stories focusing on user value for the business logic level and use another solution to handle the multiplicative complexity of the system. The other solution currently relies on traditional methods for requirements and design.

In effect, I am liberal in what constitutes my product backlog. It's not just user stories.

December 22, 2016

Code Inflation in /bin/true

—Code mass is increasing even for simple things.

A friend provided a pointer to Code Inflation, published in IEEE Software (March/April 2015). It's an look at the growth of software and highlights this growth through the use of /bin/true and /bin/false over a twenty years or so. The statistics are staggering.

This article introduces some laws:

Software tends to grow over time whether or not a rationale need for this growth exists.
All nontrivial code contains defects.
The probability of a defect increases with code size.

And some wonderful advice: Instead of just adding more features to the next version of your code, resolve to simplify it.

This article references a paper by Rob Pike and Brian W. Kernighan, titled Program design in the UNIX environment which discusses the problems with the growth of cat in 1983. Pike and Kernighan discuss the style and use of UNIX:

... the UNIX system provided a new style of computing, a new way of thinking of how to attack a problem with a computer. This style was based on the use of tools: using programs separately or in combination to get a job done, rather than doing it by hand, by monolithic self-sufficient subsystems, or by special-purpose, one-time programs.

This paper contains insight on the style and design of cat and points out how important identifying a single function for each tool is and how doing so leads to the creation of a computing environment that supports a level of flexibility and utility that are simply profound.

It is the single function and purpose of these tools which embodies their power and more importantly their inability to astonish during one's use of these tools. The inability to astonish here is important: the tools work as advertised with no surprise. That's a critically important quality. This leads to another important observation in this paper:

The key to problem-solving on the UNIX system is to identify the right primitive operations and to put them at the right place. UNIX programs tend to solve general problems rather than special cases. In a very loose sense, the programs are orthogonal, spanning the space of jobs to be done (although with a fair amount of overlap for reasons of history, convenience or efficiency). Functions are placed where they will do the most good: there shouldn’t be a pager in every program that produces output any more than there should be filename pattern matching in every program that uses filenames.

A simple read that takes a similar stance is a book by Kernighan and Plauger called Software Tools (and an updated edition titled Software Tools in Pascal). Software Tools provides unique insights into the same philosophy of functionality and combination that made UNIX work so well.

Some different perspectives on UNIX philosophy: Simplicity isn't simple.

November 29, 2016

Story Points and Complexity

—Story points are more than just complexity.

In Story Points and Velocity, I reference Mike Cohn's book "Agile Estimating and Planning" and his view that story points are a relative estimate of the complexity, size or risk in a story.

My software team and I moved away from estimates in man-days to story points. In doing so I placed a heavy emphasis on the relative aspect of story points and use a story point baseline to keep track of the relative measures created by the team for the stories they work on.

To move the team away from the notion of man-days I emphasized complexity as a means to measure stories. This worked for several months until people began to raise questions regarding what is complexity.

To being the discussion, I floated several perspective on story points. These included providing the team with the following documents.

I included the last article because of its emphasis on the relative nature of story points and its comments on haggling over definitions of complexity. My prescience proved correct. We spent 30 minutes discussing the matter and ended the meeting with an agreement to revisit story costs during the retrospective. I failed to convince that it's the relative ranking of stories that are important to the velocity calculation.

In my description of story points I emphasized that the by selecting powers of 2 as our scale we need only agree that stories are twice or half as complex relative to the stories in our baseline.

I have a problem with relative costing using Fibonacci numbers because it's difficult for me to judge the difference between a 2, 3 and 5 point story. I am much more confident that halving or doubling the cost is an easier question to answer. If I run into a 3 point story I am happy to count it as a 4 and move on because I don't place an lot of emphasis on making "accurate" estimates.

I emphasized that it's not so much the number we are interested in, although you can't diminish its importance. I feel that the cost exercise is an important element of gaining consensus on what a story really encompasses. I tend to drive cost discussion using outliers. Not so much to rein in the costs but to ensure that the outliers explain their thinking and observations on a story and then build consensus on the cost.

Curiously, the story point baseline has proved invaluable. It ensures that simple questions can be asked about a story being costed. Those questions revolve around whether people are convinced that the cost of the story is like a story (or stories) in the baseline.

October 31, 2016

RBTLIB - A Client-Side Library for Review Board

—A look at a client-side library for Review Board.

I’ve been experimenting with a simple client-side library for Review Board. I named this library RBTLIB (RBTools Library). I have a basic implementation for obtaining the Root and Review Request resources from a Review Board instance.

RBTLIB started life as a project to answer how many review requests were entered into Review Board during a fixed period of time. I extended this project to see if it could become a passable RBTool replacement.

In creating RBTLIB, I mean no disrespect to the RBTools authors. RBTools provides a rich set of use cases to guide the development of RBTLIB.

During development I discovered Click, a command-line tool for Python applications. Click is simple to use to develop command-line tools.

I spent time studying Eli Bendersky’s PSS. If you enjoy learning by example, Eli’s code is an excellent place to start.

RBTLIB is primarily an experiement in developing a client-side library for a RESTful API. I set out to develop a small tool to query a Review Board instance for any reviews added during a 24 hour period. The command-line tools built using RBTLIB can answer this question.

Some challenges remain.

First, the command-line tools return JSON objects. I don’t have an answer to this challenge. It might be reasonable to leave the command-line tools as examples for other client development but this just skirts the problem.

Second, these tools provide support for only a few Review Board resources. I’m looking at ways to represent resource data programatically. It might be nice to write “root.json” or “root.capabilities.git” to access the entire Root resource as a dictionary or just the Git capabilities.

I like the layered implementation for the Root request and the Review Request request I created. For example:

It does a nice job of leveraging the structure of the Root resource and its links. So nice that I can write a Review Request getter in a single line:

get = root.links.key(
    'review_requests',
    'application/vnd.reviewboard.org.review-requests+json')

See: rbt/rbtlib/review_requests.py

Two design objectives I set for myself in writing RBTLIB are:

Keep the Python implementation simple. RBTLIB is written in a simple style that enables additional getters for resources to be written in a single line.
Expose the entirety of the resource to the client. RBTLIB exposes the Python dictionary created from the JSON response to the client. While this approach achieves the objective the current implementation is deficient because the command-line tools simply pass this dictionary along to the user.

The next revision of RBTLIB may include an implementation of the Composite design pattern that allows the library to dynamically generating a structure for accessing the elements of the Review Board response. I’m going to try and maintain simplicity by avoiding the use of Meta Classes and if successful, I should be able to improve the results returned by the command-line tools.

Source: RBTLIB v0.1

Newer Page: 25 of 41 Older