Category: Agile

Posted on

Why can Agile only apply to Software Development?

Maybe it is just me, but it seems that it is difficult to get the notion across that Agile is not limited to development of software. In Agile communities people seem to be extremely focused on development of software, preferably a web application.

I have always worked in ways which are Agile in value, mechanisms and effect. But they are applicable to development of anything, from systems including hardware to businesses and enterprises as a whole.

When I met Ken Schwaber in September 2007 we talked about his new book, “Scrum and the Enterprise”. I immediately recognized some of the patterns he seemed to paint. Or maybe the patterns matched what I had been looking for.

However, Ken seems to have had the same problem that I seem to face, when I talk to agilists about a broader perspective of Agile. Or maybe that is “out of scope” of Agile…

Posted on

“I need a pen!”

“Do you have a pen?” … After a few minutes the answer is “Sorry, no.” What if the question would have been “Do you have something to draw with?”. Maybe a pencil, or chalk could have been found. And better yet, “I need to draw. Do you have a pen?” This signals not only the need, but also a prefered set of properties on the solution. These properties are not requirements, but can still be used as input.

Does your requirements process work like this? Or do you have “Must Have”, “Could Have” and “Nice to Have”? It is the need, and the implied and fuzzy priorities, that is the essential part of agile requirements management work. These are seldom articulated in standard requirements mangement processes.

Posted on

Project Models Overview

On the mailing list of Agile Sweden there was recently a long thread on models for life cycle approach to software development and the Agile community received some critique for maybe not having tackled this view, and of course the favourite topic of “project” was raised. The rest of this post is a translation, with some minor edits, of a post that I did to that mailing list, where I tried to summarize my views on “projects”. This was among other things inspired by a blog by James Shore where he described his way of managing the incorrect use of the term by the rest of the world.

I think the rigid command and control mentality evident in many of models and thinking of the last few decades stems from an increasing suspicion towards larger and larger projects with continuously increasing complexity. And rightly so. As we (the engineering and technology community) have become masters of the current technology, we have tackled even more complicated and challenging projects, and of course the amount of “failures” has grown, or at least the economic impact of the failures. The natural reaction is to try to control everything down to every little detail, thinking that detailed control leads to overall control. The problem is of course that this has been the wrong solution to the problem.
Continue reading “Project Models Overview”

Posted on

Agile Practices Cross-Reference

Blogging is about sharing so I’ll share a blog from James Shore with an excellent table of Agile Practices across XP1, XP2 and Scrum (too bad no other models where represented, but Somebody Else should maybe do that…). The table is here.

Posted on

Hosting Open Space sessions at Scrum Gathering

All of us at Responsive attended the Scrum Gathering 2007 in London. As usual it is most interesting, pleaseant and informative to attend these international conferences. Although the organisers was very explicit in making the Gathering more of a social even, it was still very much of a conference, at least for the two first days (not counting the course days). They where so filled with tutorials and other interesting presentations that it was almost possible to choose, let alone make time to talk to people in the short breaks. I would really like the next conference I attend to actually force people to talk to each other during the conference.

Fortunately the third day (Friday) was totally devoted to Open Space, a form that I enjoy very much. This time I hosted two sessions, “How to find Product Owners” and “Enterprise Scrum and Large-Scale Systems Development”. The latter I co-hosted with Henrik Kniberg, who was confused about what Ken Schwaber actually ment in his new book (“Scrum and the Enterprise”).

My take was really not a response or defence to Ken’s Enterprise thoughts, but rather a presentation of some thoughts that I have carried for a long time on how to scale Agile, Iterative and Incremental development to the large scale systems of systems domain. It turned out that these two topics was not exactly compatible so a part of the session broke out to create a concrete example, while the other part continued with more theoretical discussions and comparisons.

My biggest insight from that session was, again, that there are more flavours to development than any single person can really have concrete experience with. Many agile people I meet at conferences seem to have extensive experience with lightweight web or application development, but those with the most questions are usually from the “harder” part of the spectrum, like military, safety, financial or security development. So, I will have to remember to present the concrete problem that “my model” is trying to solve, before engaging in a discussion.

Posted on

Software as a Corporate Asset

I just came across a video recording of “The Canary in the Coalmine” from Agile 2006 where Ken Schwaber discusses the factors involved in getting companies to realize that software is a Corporate Asset. My conclusion, having seen many of the same effects in a number of companies, is that most of the decisions about projects status, schedules, delivery dates, features suffer from the same problem; they are not based on facts, or at least not on all the facts. For example, which is one of the main points in Ken’s presentation, the future cost of not having software that is well-kept, which in turn is a direct effect of pushing deadlines and increasing feature sets.
As a case in point, Ken’s anecdote from the “$14M, but just some features more” situation, is an example of how easy it is to make enterprise level decisions without hard facts, and what it might lead to.

Posted on

Bowling Kata “solution”

One of the most famous katas (excercises) for TDD (test-driven development) is the Bowling Kata. There are some sites that describe the Kata, which has the following “stories” as input:

  • A bowling machine want to report the number of pins the player strikes down for every roll the player does
  • A bowling player want to see the resulting score of a completed game

It is actually a rather simple Kata, but never the less allows for demonstration and training of some TDD tasks and strategies. But of course you need to know the bowling rules…

We have used the Bowling Kata for our Coder’s Dojos, and have learned a lot from it. The following is a recording of one of my solution to it :

Posted on

CHAOS or not?

The CHAOS reports from the Standish Group has become infamous, so much so that Sean Hanly made us promise to never quote the figures as evidence against the traditional models. However I recently found an interview that Deborah Hartmann at InfoQ did with the Standish Groups founder and chairman Jim Johnson. In the interview Deborah asks some really interesting questions and Jim’s answers seems straightforward and honest. The relatively fresh statistics presented is interesting, but most interesting of all is the list of success factors, where it is obvious that the Agile values and methods addresses most of the top 10 with concrete techniques.

Posted on

What is “Agile” all about? Really?

This is actually post that I did over at forum.agilesoftwaredevelopment.org in a tread with the above name. Finally I was prompted to articulate some of my thinking around this “popular” issue.

Ursprugligen inlagt av RonJeffries

Originally posted by red2
Wouldn’t you also say that Agile was a framework for enabling intuition to be quantified within an environment which prefers more empirical measurements? After all Agile would seem to be about divesting control from procedure to people.

I would certainly agree that agile is about moving the center of control away from procedure and toward people working together.

I would also say that partof what Agile does is enable “intuition” to be applied.

However, I’d want to be careful with the term “intuition”. It’s a weak, and perhaps dismissive term when we use it to describe the combined experience of a group of people, brought to bear on some problem, when they are freed from their cubes and are enabled to work together.

Who am I to disagree with one of the original signatories 😉 but I am not sure that I agree that the “agile is about moving control away from procedure”. I think is actually an effect of the fact that most procedures used currently does not make it easy to become “agile” enough.

What I mean is that since most current procedures are stipulatory, rigid and founded in other values than the “true agile values” (which I’ll come to in a second), they will not be possible to follow to achieve true agility. But there is no inherent conflict in procedure and agility, just look at XP. It is full of procedures, but achieves high degree of agility. Daily stand-ups is certainly procedure!

Agile is not about techniques either. Techniques are, as procedures, just a tool to get to the result, so we must look beyond both to find the “true agile values”.

*I* belive that the true values of agile is what it delivers to the stakeholders of the activities. E.g. delivering software that is usable for purpose, delivering business values or whatever the primary stakeholders require.

The techniques, and tools and procedures, that we apply are only secondary. However, there are some techniques, tools and procedures that we agile people think *must* be applied to deliver on that stakeholder interest, which are different than what we previously have thought, and been taught. Namely, an intense closed feedback loop! To optimize this feedback loop we find that it does not work to do big design upfront, waterfall projects, etc. etc.

Instead, to tighten this loop, we communicate directly with customers and users, develop a single feature at a time, get concrete feedback, and so on. The more we can tighten this loop the more efficient we are able to deliver the best result possible to our stakeholders.

Agile is not about a fuzzy feeling of people getting together. It is based on hard, cold evidence that tight feedback loops are the best way to deliver in this world of constant changing requirements, “I know it when I see it!”, and developing features no one can imagine the full impact of. One of the most important factor in tightening this loop is to get people to talk to each other, but that is not an agile value. It is a necessity to deliver on the true agile value: best possible working software/system/product with the given resources!

Would agile have developed if Waterfall would have worked? I would say no. Agile has evolved because previous thinking did not perform to our satisfaction!

Posted on

“Pairing with Thomas”

I came across Ron Jeffries book Extreme Programming Adventures in C# on Agile Alliance members page, a book which he thinks should be called “Pairing with Ron”. It’s about the development of a small XML editing tool he did. But it describes every little test, refactoring and other anecdotes that are relevant.

I thought this to be fairly interesting, and since I have just started on a similar journey I though I’d start some kind of log of it here. Of course I have already done some basic things so I try to make this log catch up quickly.

I am trying to build an Object Application Modeller. The basic functionallity is to be able to define classes with attributes, relations and views. I have seen many applications where this is actually the basic functionallity, so maybe this tool exists already but since it’s a journey the goal is not the value, the journey in itself is.

The trick is to be able to “generate” an application from these definitions, with support for persistence of the instances of the classes and relations of course. *AND* with the possibility to upgrade, which will introduce the need to refactor the persistent storage (a.k.a database) on upgrade.

I’m sorry that I will not be able to remember all the steps I have already taken, but here are the initial list of User Stories:

  • Define and Delete a Class
  • Save an Application Definition and Restore it
  • Add a (String/Integer type) attribute to a Class and Delete it
  • Create instances of the defined classes (implies deploying the Application)
  • Display instances as a table with attibutes
  • Select which attributes to show
  • Sort and filter data according to specific column
  • Define Relations with attributes between specified Classes
  • Show instances with attributes in a tree using a specific relation showing attributes
  • Show instances with all relations
  • Deploy an updated Application Definition to an existing Application

So I started with a test that creates a Dictionary, adds a Class to it and then looks up that same Class. No problems there, implemented the Dictionary as an ArrayList which took Class.

Then save and restore, almost as straight forward. Decided to use a simple text file with one line per Class.

Then, GUI! Since many have talked about thin GUI:s I first decided to use the Eclipse Visual Class editor to just add a simple GUI on top of the functions. That was just somewhat successful. And it felt bad. Why couldn’t I do TDD on the GUI?

Having introduced Automatic Testing of the webapplication in my current project I knew there where a multitude of GUI testers, but I surely did not want to go down the path that lead us to Mercury Quicktest Professional!!

But I found Abbot, “A Better Bot”! It drives and inspects Java GUI, and JUnit functionallity to boot! So I added some tests to drive my GUI components, and of course I had to refactor those a bit to make the testing easier.

So now I could add tests to drive adding attributes. And since I implemented those as ArrayLists too I refactored out an ItemList to hold Items which became a super class to Class and Attribute.

I have just added a test to drive adding attributes from the GUI. The first test is to select a Class, press the Edit button and ensure that an “Edit Attributes for Class” window appears. And that’s where I am now.

To be continued…