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 visible… Read more »
Posts Categorized: Agile
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, SCRUM… Read more »
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 [...]
For the majority of agile teams user stories are the preferred tool for requirements management. User stories provide numerous benefits including; a focus on the business problem being solved, a just in time approach to specification, amenability to splitting that supports working in short time-boxes.
The problem with user stories in practice is that the desire [...]
My current client is a major telco. They have been developing high qaulity software for decades (literally). They have heavily entrenched waterfall process. They are used to doing everything to the letter of their methodology. When I first came on site two years ago I used to dispair of them ever doing anything agile.
Today, they seem to be doing agile pretty well. Its not been a universially posiitve experience and there are plenty of non-agile values and practices still floating around. On the whole though I have been impressed that rather than seeing Agile as an excuse not to write documents, they have embraced the disipline required by a leaner software process.
I have worked with clients who were much more reactive and used to being at the cuting edge. They embraced agile becuase it appeared to legitmise the lack of structure in their approach. They produced poor software when they produced up front designs and they continued to produce poor software when the developers were ‘let off their leashes’.
Upon reflection I think my current client, with its long history of rigour and application of best practice has made far better use of the agile techniques. Maybe its becuase they continue to apply disiplince. Possibly its becuase they are very aware of the dangers of a less formal approach and are always trying to mitigate any risk that not having the waterfall in place might bring.