I was recently asked to help a client kick-off development of a new product. This was to be their first “agile” project so the kick-off had to set the scene for the collaborative development approach that was to follow.
I used a variety of tools and techniques to bring the project to life. As is usually [...]

Take-away #3 from David Anderson’s Kanban Coaching workshop.
A discussion of Kanban can only go on for so long before the subject of the Theory of Constraints comes up. In this post I’ll try to explain just enough to show this connection.
[...]

Tweet By Jorge Migueis When a team adopts Agile processes, they can sometimes forget to retain the good practices from the “old” processes. One of these forgotten practises is Risk Management. People are going to rightfully argue that Agile will ensure that the constant feedback loops of daily stand-ups, demonstrations and retrospectives make issues more [...]

Tweet See a new article on Agile tools by Jorge Migueis here. We work in the IT industry where we build tools with the aim of helping our clients or company to be more efficient. However, sometimes we forget to do the same for ourselves. It is often said that Agile methodologies such as XP, [...]

I have spent the week at the Agile2009 conference in Chicago. This annual conference, now in its eighth year, is the premier international gathering for agilsts. It caters for a whole spectrum of experience from new comers to the discipline to the gurus who are leading the way.

I attended some very thought provoking sessions as well as presenting my own experience report on techniques for technical architecture in an agile context. My colleague from Valtech US, Howard Deiner, battled hardware and network issues to present a well received demonstration of Continuous Integration. Both sessions got reasonable attendances in the face of stiff competition from competing presentations being held in parallel. Both received very positive feedback from attendees (mine scored 80% for command of topic and 78% overall). I got lots of positive feedback for my session in conversations with conference attendees throughout the week. This was very much appreciated.

My presentation is backed up by an IEEE Report which was published in the conference proceedings. The report’s premise is that incumbent waterfall software development processes force technical architects into a position of isolation and ineffectiveness (the ivory tower). The challenge I (any many many other TAs) have faced is how to deliver the guarantees of technical correctness and consistency that clients (especially those moving from waterfall to agile) demand when some of the most widely used conventional techniques for architecture have been discredited. I am thinking primarily of the emphasis placed on up front detailed design and architectural review.

The report details architectural problems during scale up of a previously successful agile project. The report then describes and evaluates a number of techniques employed on the project to deliver the technical architecture without ascent of the ivory tower. The conclusions include the justification that documentation is not an effective tool for technical governance and that the architect must target activities which bring them closer the the actual implementation. This mirrors Neal Ford’s point in his Emerging Architecture presentation that we need to accept that the real design is the code, not the summaries and abstractions of the code presented via the numerous tools (UML, narrative documents, whiteboard sessions) at our disposal. Other conclusions include the identification of automated tests as an architect’s, not just a tester’s, most effective tool for delivering a correct solution. The paper also identifies that soft skills around communication and people management, often the anathema of the conventional architect are critical to success. Finally the report concludes that utilizing the most cost effective techniques (rather than just the most technically powerful) were key. (That does not mean you cannot justify the use of expensive techniques, just that they may only be justifiable on the most important components in the system).

Agile 2009 was a great balance of real world experiences (such as my session) and more philosophical, academic sessions. There also the chance to listen to some insightful keynotes and take part in some exciting expert sessions which challenged the way we work. It is always easier to learn in a community of professionals with real experience and this was definitely the case at this conference. I learned as much over dinner and in break out sessions as I did in the formal seminars.

I am going to blog what I learned in some of sessions in the next couple of days, possibly earlier as I am stuck at Chicago O’Hare for eleven hours after a ‘mechanical issue’ with our plane!

Given the complexity of most software systems why do we still insist on primarily documenting and elaborating requirements in text? I think the main reason is that writing comes so easy to us where as producing a more visual representation of what we mean requires more of an initial learning curve.

A more visual representation is easier to process and understand. It is also less ambiguous then natural language on it’s own. It can form a very good basis for requirement elaboration. Please note,…

I met with a potential client last week and found my self answering the question, “what, in a nutshell, does agile mean?”.
To date I’ve never had a canned answer to this and can come from various directions perhaps talking about the history and how it’s an umbrella term for a whole bunch of things [...]

Agile Project Metrics should be at the level of abstraction of the target audience but answer the following questions at all times:

- Where are we?
- Are we on track?
- Are we in trouble? Why?

This is first of a series of blogs to explore the importance of metrics in an Agile project. The approach to a specific Agile project is often described as emergent. In the sense that we don’t start off with a prescribed approach in mind but we adopt as our understanding of projects grows and it’s profile and key challenges emerges. Agile metrics can be used as an aid to understanding a project’s profile (informational metrics) and it’s challenges (diagnostics metrics). The following is a list o…

SCRUM and Kanban (as applied to software development) are different. Proponents of the two drift from staunch opposition to declaring Kanban as a special case of Scrum.
I have been practising and coaching Scrum for a number of years and I delight in the effect it has on project teams. While I practice Scrum I find [...]