Two Sprint Equations

What should be the order of items to do when installing a Sprint process from scratch? In the coaching days, we requested one to one ratio between the coaches and the rest of the developers plus a project manager, go all out for a couple of sprints, give everyone a chance to adjust to the process, before adjusting the process to the team.

For a single person, the strategy would have to be different. You would need to look at all the practices and make trade-offs with eyes on the big picture. The following two equations are what kept popping into my mind as I am installing the process to the two teams.

Value = Scope * (Feature Quality * Code Quality)

One comment to make here is that during the product development, these three factors are sometimes working against each other. A good business analyst or product manage is one that knows how and when to balance them. Only then, one with a strong personality can bring the best value to the product.

Scope is measurable, as the second section will show. Feature quality and code quality however are simply not something can be determined by objective measurement, not purely on it anyway. When pushed on something like a scope, the things that are not measurable get sacrificed, and everyone ends up paying for it sooner or later.

Scope = Velocity * Number of Sprints

Assuming that the quality of the product is controlled, the scope would be the next thing to look out for during a project. This is pretty easy to understand: the more the team can do without sacrificing the quality (both feature quality and code quality), the better.

Velocity is something that can only be affected by tuning the Sprint process of the team, but can never be demanded. What is left for this equation to work would be to adjust either the scope of the project, or the time of the project (number of sprints), and most of the time both. This is probably one of the commonly stated facts, at the same time it is probably also one of the most ignored fact.

Boosting velocity is the same as boosting productivity of the team, which is the job for the team lead. This is the purpose of a lot of XP practices: TDD, paired programming, co-location, shared ownership, continuous integration.

Ask "Why Do You Ask"

As a traveling consultant working for a company pushing for agile, I keep on being asked for similar question repeatedly. "What do you do in stand-up?" "Why is TDD good enough to spend time on?" "What do you mean the velocity is 20 this week, 25 last week, and 18 the week before???"

Naturally, I trid to come up with the best answer based on the experience I had had, the books and articles I had read, the other conversation that I had had with other people, and the understanding that I had gained about the one who asked the question. Slowly, my answer to the above questions became bigger and bigger, with more details, more angles, as if I was getting closer and closer to the truth.

WRONG...

What I have realized in the past year, was that the best way to answer these questions, actually, are:

Give a 30-second brief answer. Stop, and ask: "Why Do You Ask?"

Different people have different situation, and are seeking the solution to different problem when asking the same question. In this case, giving a by-the-book answer, no matter how pragmatic or complete it is, does not necessarily solve that problem.

Here is a true case.

When I was traveling in China, I stayed late in the office one day to do some market research and spike on BuildMaster project. Another ThoughtWorker, who was doing some of his own thing, turned to me and asked "So what have you been working on lately?"

Since he expressed interest in DbFixture before, and that I knew he was on beach at the moment, I thought he was looking for something interesting to work on. So immediately I went on talking about the problem that I was trying to solve and the "grand" vision that I had with BuildMaster, Cotta and jBehave. I went on for 5 minutes (if not more) and realized none of them gained any interest. Going out on a limb, and out of a bit frustration, I finally asked the million-dollar question.

Turned out that he had an idea of starting an open-source project to help WebServices testing and would like to get me involved because of all the xFixture projects that I had been working on.

Granted, it was not exactly a straightforward question. Yet more and more I start paying attention to the motivations behind the questions rather than the questions themselves, and even sometimes observing the conversations others have.

And the rest is history.

I can now control myself much better nowadays instead of "blah blah..." for minutes.

Otherwise, I might as well say "42"

Feedback from the Client

I have meant to post this a while ago, but with the traveling my daily schedule is still not settled. So I never found a good time that I can just quiet down and write some blog.

This week is a short week due to the past long weekend. So we were able to convince the client that it is better for us to work from our home office so that we don't need to spend two days traveling for a four-day week. And once again, I am able to continue my routine of blogging.

After my last enablement project (now the term is "transforming" because "enablement" has been used along with "training". I will explain that later), the client team had a project retrospective, discussing what they have learned during the project.

With their still fresh memory, they were able to extrapolate the following, with which they gave the presentation to the rest of the organization. They are nice enough to let me publish this. I hope this can be useful for some of you who are still wondering about agile software engineering, or at least some of the "weird practices" that I have been defending from time to time. This is the first-handed note. Hopefully I can help them revise the format for more formal presentations.

Agile: One Developer's Perspective

What methodology did we use in the past?

• It doesn't have a name, as far as I know, but here are some features of it
• big upfront requirements-gathering, big upfront design, with some formal and some informal documentation
• one developer per application, or a couple of developers working in different tiers of an application
• integration & testing in a big bang at the end
• manual testing

Some problems we had with this approach

Big upfront...

• late-breaking requirements changes combined with inflexible deadlines led to periodic frenzies of coding that eroded the integrity of the big upfront design
• sometimes we specified & designed more than we could actually implement with the time and resources we had
• integration late in the development cycle led to periodic frenzies of coding that eroded the integrity of the big upfront design
• disagreements about how open we should be to changes

One developer, or a couple of developers working in different tiers of an application...

• we didn't always take advantage of possibilities for using some common code or common approaches across applications
• difficulty scaling up for larger efforts
• the culture of code ownership by individuals was sometimes at odds with our "esprit de corps"

Integration & testing in a big bang at the end; manual testing...

• huge burden placed upon QA (when we had QA at all)
• difficulties detecting the ramifications of maintenance changes, so we became timid about upgrading applications and we ended up with multiple versions of the same module in production
• we often had as many opinions about how close we were to being finished as we had team members
• we did not know how to thoroughly test componentry; we could only test built apps

For me personally, the biggest problem was that I was unhappy. I felt that our team could be great, but we just couldn't get there, and I didn't know how to be "part of the solution".

Enter Thoughtworks, with a philosophy and a toolbox

Some things I was immediately enthusiastic about...

• Eclipse IDE (Great no matter what methodology you embrace)
• Automated testing
• Daily standup meeting
• Frequent discussions as a group about what is working and what isn't, so that we can make incremental corrections in our direction
• Realistic attitude towards estimating: as the project progresses, we can get more accurate in our predictions of a delivery date, but we can't expect perfect accuracy at the beginning.
• steady pace, avoiding individual heroics
• Simplicity--the art of maximizing the amount of work not done--is essential. (From "Principles behind the agile manifesto" http://agilemanifesto.org/principles.html)

Some things I was skeptical but open-minded about...

• TDD
• Test-driven development requires that a unit test be written for each tiny piece of functionality before you write any application code
• The unit tests are written by the developers, not QA
• Although "test" appears in its name, test-driven development is not so much about testing as it is about enforcing a development discipline that makes refactoring possible
• The unit tests serve as documentation of the developer's understanding of requirements
• "radical co-location"
• continuous integration
• fully automated build and test process that allows a team to build and test their software many times a day
• everybody using the same code base, checking in and updating their code very frequently
• at first, I was incredulous that checking in and building as frequently as once per day would even be possible; TWers viewed once a day as a minimum

Some things I was deeply skeptical about...

• paired programming
• code ownership is to be avoided
• evolutionary design through refactoring

Martin Fowler's definition

What is Refactoring?
Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a 'refactoring') does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it's less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.

• very short iterations
• less emphasis on formal documentation
• "embrace change"

A year later
Life on our team is completely different than before. From my perspective, it is much better.
Did the philosophy and the toolbox make a difference?
Yes, but not all by themselves. We had to have...

• the right attitude
• one-on-one mentoring from experienced agile developers
• effective leadership
• discipline

Attitude
We could not have made changes as extensive as this without

• positive attitudes
• team spirit
• perseverance

one-on-one mentoring from experienced agile developers

• from the agile manifesto: "value individuals and interactions over processes and tools"
• TDD feels initially so unnatural, that it is essential to have a patient, experienced person at your elbow
• without discipline, the agile philosophy can degenerate into "a license to hack", so it is important to have constant reminders about the discipline until it is second nature

effective leadership

• the project manager may be an exception to the general principle that individual heroics should not be required
• protected the group from distractions
• keeps both the big picture and myriad details in mind
• inspires confidence

discipline

• do not write even the smallest method without writing a test first; see the test fail, then write the minimum amount of code to make it pass
• update from the repository frequently, run the entire test suite before each check-in of your own
• builds & test suites run continuously; if your check-in breaks the build, STOP and fix
• to maintain design and code integrity, coding decisions are made in pairs...if the pair can agree, go forward

If the discipline is not observed, then we can't "embrace change" and "evolve the design through refactoring" because we can't be confident about extensive changes.


Notes

• http://www.martinfowler.com/articles/newMethodology.html#id2249560
• http://loki.lokislabs.org/weblog/archives/2003/11/15/radical_collocation_is_a_good_thing.php

Below is a summary of BTM/70, a methodology in use at a job I had 20 years ago at a company. It is probably an example of what the "value individuals and interactions over processes and tools" principle is a reaction against. All that I remember about BTM/70 is that there were big binders of sample forms, and every step of the way, one had to photocopy the appropriate forms and fill them out. I do not recall any specific benefits.
The life cycle of an BTM/70 project consists of eight (8) phases ranging from Systems Requirements to System Implementation. Coupled with BTM/70 is ET/70, a Project Control tool set that is used for project planning and tracking. ET/70 assists in milestone planning, helps establish project target dates, supports activity tracking, and detail time reporting of each staff member down to the task level, within each activity, of each phase of the project