Category: Agile

Posted on

Measuring Business Value

Measurements is a two edged sword. On one hand you cannot see and compare something that you have not measured. One the other hand there are evidence that it generates dysfunction. Conciuosly or unconciously we tweak our ways to get good numbers. We all know and love the story about the development organisation that was to be measured on the number of comment lines in production code. The tool to insert the correct number of comment lines was available just a few days later.

We need to measure, but most organizations seem to measure the wrong things. I think Systems Thinking and Lean can teach us a bit about how to measure in a meaningful manner. Systems Thinking (and Gödel for that matter) keep pointing “one level up”, i.e. don’t measure inside the system, instead measure the system.

Lean (and Scrum and XP) indicates in various ways that we should prioritize according to business value which seems like a good proposition. So I try to convince managers in my client organizations to measure flow of value through the development organization, and as Lean puts it, measure the whole. (Which in itself can be hard, but at least it is not only the development team!)

However, the notion of business value is a fluffy one. And it is usually very hard to get anyone to assign dollars and cents to a customer request in the general case. (Unless you’re a contract developer, when it’s kind of easy, but probably wrong!)

So what I am trying now is to use business value points. In the same way as Story Points work for effort estimation, Business Value Points can be used to let marketing people, business analysts etc. assign relative values to requirements or features.

One complexity still left to address is the fact that at early stages requirements etc. are fairly large and later broken down and re-prioritized. This means that a complete “requirement” is seldom delivered. So the Business Value Points needs somehow to be split when a requirement is split into Epics and Stories.

But if we could measure the flow of value we can also optimize the whole and avoid sub-optimization and measurement value tweaking.

Posted on

Agile Anti-Pattern: Over-Generalisation

This is the first in a series of posts in which I will try to collect my view of problems in introducing Agile techniques in an organisation, forces that work against Agile and traps that are just waiting to catch the unwary agile practitioner.

Slogan

Generalization makes useless

Applies to

With the obvious risk of falling into the Agile Anti-Pattern: Over-Generalization this Anti-Pattern can apply to many different types of items:

  • Goals
  • Definitions of terms
  • Requirements
  • Plans
  • Stories
  • Definition of Done
  • Tasks
  • Implementation

Examples

Programmers often feel a need to write robust source code. If the exact circumstances in which the code will be executed is not explicitly stated, it is tempting to generalise, second-guessing any future and currently unknown situations.

Exactly the same thing might happen for requirements. A stakeholder might be very broad in his description of the need. But it must be broken down into more and more concrete examples. We know that “The system must react fast to any user input …” is not a requirement usable for development. It might be usable for validation in system test though, because it is a value articulated by the users, and as such can be subjectively validated. But it does not give the concrete information to know when it is actually done.

Over-Generalization in definitions of terms is also common. I have seen it often in planning of business change programs. Particularly in large organizations, where there are many different types of products, situations and projects, definitions of practices easily becomes to generalised to be useful.

For example, in a transition to Agile, the practice “Continuous Integration” might be taken to mean

  • all tests and integrations are automated
  • there are no manual tests
  • system tests are done automatically

… and more. It is not that these goals are bad, in fact they are excellent. But at the core “Continuous Integration” probably means something like “giving programmers concrete feed-back of every change as soon as possible by running builds of as large part of the whole product as possible and as large set of tests as possible as soon as possible after every change to any part of the source code”. As for any change that is to be implemented we need to know exactly what we are trying to implement.

Often people want to include their particular situation, need or interpretation into a definition. The mostly generates bloat. This might also be one of the causes of “requirements creep”.

If a definition is taken to encompass everything related, the definition becomes useless.

Remedy

The best way to handle Generalisation is of course to break down to concrete or less general items. For source code this is already addressed in Agile software development techniques. As the saying goes, don’t implement anything that the current set of tests doesn’t require. This makes us do the simplest thing that could possibly work. This is good advice in any circumstance, and at the core of Agile.

However, sometimes this is not accepted by some of the people involved or affected. A common pattern to this resistance to simply is that it could be perceived as making one persons particular definition or need out of scope. One technique here is to separate that particular part of the definition out into a separate item. It is important not let this come across as removing it, particularly to infer less value in it. This way it is usually possible to get a concensus on a set of tighter, more concrete, items.

Once a set of more concrete items has been agreed upon, a prioritisation process can commence. So it is important to have this prioritization step when handling all types of items. This separates the assignment of importance from the concretisation.

Posted on

The Fifth Element

Uncle Bob has recently published an new book, “Clean Code”. In it, as I understand it, and in his energetic keynote at the Agile 2008 Conference Dinner keynote in Toronto, he talked a lot on the subject of Craftsmanship. He proposed a fifth element to the Agile Manifesto, “Craftsmanship over Crap”, or as he revised it in his blog, “Craftsmanship over Execution”.

I fully agree that our work requires craftsmanship and ethics and a lot of other things to be carried out with quality. However, I do not agree that there is a need for this to be a fifth element. I think that by examining what we mean by “Working Software” it is not needed.

“Working Software” does not mean “it’s done, since it is running”. To me it means that it actually works, in the same way that it fullfills *all* of its purposes, “fitness to purpose” if you will. This would mean that not only does it function, it also gives a positive user experience, is fit for future change, has quality enough to not surprise and so on. I strongly believe that the term quality do include all dimensions of such fitness.

Usually “Quality” is used in a more restricted meaning, which takes away from its broad spectrum of value. Again, by viewing “Working Software” to include this dimension we don’t need any specific craftmanship element. If anything, I think that David Anderssons suggestion of a fifth element has more merits. He proposed a fifth element focusing on Continous Improvement, which I think is at the heart of Agile, and unfortunately missing in the Manifesto.

Posted on

Blogs about my Toronto presentation

Ronica, a coach from Rally, have blogged about my “GTD + Kanban + Round Robin for Product Owners” presentation. It is actually a good and correct sum up of the content, so go read it!

In a sum up on pull system presentations at Agile 2008 Corey Ladas mentions my presentation. He doesn’t indicate if he went to see it or not 😉 Jim at Modus specifically says he won’t be going, but points to Kanban and Pull Systems presentations at Agile 2008 in this blog. Karl Scotland recommended my presentation as one of the ones you should attend. Again it is unknown if he went.

Posted on

Toronto presentation

View from my Toronto hotel roomI have just finished doing my presentation at Agile 2008 in Toronto. The presentation was titled “GTD + Kanban + Round Robin for Product Owners” and was an extended version of one of my lightning talks from “Agila Sverige” in July. I will get back and blog a bit about how the idea was born and how we actually used that in my latest project. Meanwhile I will provide the presentation here in Flash and PDF format.

Posted on

Single-point, Multi-point

There are many things that are different in the “new world of development” as opposed to the way it was in “the old”. One of the more subtle, but perhaps fundamental is the way that decisions and communication has switched characteristics.

When a developer was developing code “in the old days” he or she had a task defined by some designer, project manager or architect. This was usually the only point of communication that was available to discuss the features. But frequently sales persons or other customer contacts would show up at the developers desk and ask about some features, estimates or changes that could be made “since doing them at the same time would not cost anything”. This single-point communication, multi-point control has been one of the primary sources for unpredictability in the “old” way. Although detailed plans was made and project managers tried everything possible to keep them, the urge from business to rush and push unplanned things into the workload of development ensured failure to meet the plans, no matter how strict control was applied.

In agile development one of the most important techniques is to enable developers to communicate with stakeholders of various kinds, users, customers, business people. This multi-point communication is essential to ensure that valuable features are developed. On the other hand decisions are focused around the product owner and his power of prioritization. This is exactly enough to work as a single point of decision. In conjuction with the multi-point communication it is “right-sized” decisions.

So removing the single-point communication, multi-point control and replacing it with single-point control, multi-point communication gives us controlled flow of tasks and predictability of development.

Posted on

“Agila Sverige” a success!

We’re back from the first real agile conference in Sweden, “Agila Sverige 2008”. There have been a couple of other conferences, of course. Some of them with Responsive as sponsors. But this was a conference arranged by the non-profit organisation “Agile Sweden”. It was mimicing the format from “Smidig 2007″,  lightning talks before lunch, and open space in the afternoon.

Andreas and me had two talks each. They seemed all to be well received. Both of my talks where listed on more than one sticky note voting for best lightning talk. So that was a personal success.

It was also a success as a conference. It was so full of inspiring talks, interesting people to talk to, some of them whom I only had had mailing list exchanges with. Nice to meet them face to face. Many of them also people on the “Computer Sweden Top List of Developers”, numbers 12, 30, 44, 49, 51, 53, so sometimes even CS is right…

But the big success was that everybody contributed. Thank you everybody!

My biggest insight was that “10 minutes is enough, you can say everything you want in 10 minutes”. So maybe Agile 2008 in Toronto will be a bore, all those 90 minute ramblings…

Posted on

Agile isn’t about trust…

Many people have said that “Agile is all about trust”, and I have sort of agreed. Up till recently. A collegue and me had a lunch conversation with Mary Poppendieck at XP2006 in Oulu. Mary talked a lot about the relation Toyota had built with their sub-contractors, how it was all trust, aligning sub-contractors goals with Toyotas and not pressuring the sub-contractors to minimize their prices, no matter what. Instead Toyota promised that if the sub-contractor could not meet the required price levels, Toyota would put people and knowledge into helping the sub-contractor reach that level. And, I suppose, the sub-contractor had similarly promised to make any changes to their operation to reach the level.

Such trust is of course the goal also of agile practices, responsible development and, of course, any other type of business relation. But us agile people can not start such a relation by saying “You’ll have to trust me…”

The software industry has burned those bridges far too many times already. “Well, we’ll try a more structured way to programming…”, “Ok, so that did not work, but trust us now, we have come up with this this object orientation…”, “Hmm, we understand that programming isn’t everything, so trust on this process and quality thing we’ve got going…” No, it is us agile people that have to interface with the “traditional world” first. They will never come to us just because we say that we can be trusted. We must find ways to prove, in real world combat, that there finally are ways to build a trust relation with a developing organisation.

http://www.dsdm.org/timebox/issue32/DSDM&Scrum.asp

http://codebetter.com/blogs/gregyoung/archive/2006/07/07/147179.aspx

Posted on

Assert-first, Backwards directed, Completion assisted Coding

Testdriven development, TDD, is a well-known technique to be able to focus on the tiny next step of specific functionality to implement. My experience from watching a number of coders in our Dojo’s, and from my own work, is that even though focusing on the test is the idea, it is easy to get side-tracked. All the little details that need to be set up before arriving at the assert statement at the end of the test are distracting. Instead of focusing on the feature the coder starts thinking about which variables are needed, their names, are there any constant values, which handy functions do we need to write. This sequential mode of coding is particularly obvious in more inexperienced programmers and splits the focus. Trying to keep many details in your head at the same time as trying to maintain the direction of the test is hard.

I’m a mediocre programmer and I have a hard time keeping all the details in my head. I need help to focus on what is to be achieved. TDD has been a tremendous help and is my safety net. But to get one step further I have started to use a technique, or rather coding style, that starts with writing the assert-statement first. Yes, just the assert. This helps me think about what the test should actually test before I think about how to set up the test. Let’s call that “Assert-first coding”.

In the same way as for the assert statement in the test, you can start with the end result in the production code. E.g. the return statement in a function is the required goal. Once the return statement is in place we can think about, and implement, what is required to get statement to compile. Step by step we can work our way backwards until we have the complete function. Let’s call that “Backwards directed coding”.

Espescially in typed languages and with modern IDE:s like Eclipse, it is possible the use the Code Completion and Quick Fix features to quickly and easily fill in the gaps and create the pre-requisites to get the assert or return statement to a runnable state. Let’s call that “Completion assisted coding”.

If you combine these techniques you get a style that could be called “Assert-first, Backwards directed Completion assisted Coding”, ABC;-) Thanks, Joakim Holm for the name. (I initially called it “ACBC”.)

I’ll get back with some screen captures to show what I mean.

Posted on

Evolution

Me and one of my current work collegues had an interesting lunch discussion the other week. He had just read one of Richard Dawkins books and we talked about the creationism and its flaws but also the style in which he argues for his view. This lead us to the development of systems and software and how that actually could be seen as evolution. Erik then formulated the following insight:

Evolution is superior to intelligent design.

Exchanging evolution for development and intelligent design for big design up-front gives a lot of insight on the natural connection between Darwinism and Agile.