Abby Fichtner – The Hacker Chick – wrote a blog entry asking (and answering) Are we agile yet?. In essence it relates the Poppendieck’s seven principles from Lean to other Agile methodologies. Since I’m currently finishing up the Quality Software Management series from Gerald M. Weinberg, I got to know about the importance to know about many models for developing software. So, I decided to expand the thoughts of her seven key points beyond Lean, Kanban, and Scrum and strive over some of the most common Agile methodologies. In this blog entry I’m going to re-visit the seven principles and expand the view to XP, and Crystal.

Eliminate waste

Eliminating waste is at the heart of Lean. Similarly in Scrum the team is asked to just implement the items from the backlog with the highest priority. In Agile Estimating and Planning Mike Cohn describes very well, that the the items with the highest priority are realized from the backlog first. Thereby the team achieves a software product with the highest business value. In QSM Vol. 4 Jerry Weinberg denotes it as the 90% of the implementation that delivers 99.9% of the value to the customer. Similarly, by working in this manner you will drop the meaningless features if you need the core functionalities sooner. Meaningless features in the product backlog are then of course an instance of waste.

XP favors the principle of simplicity. There is an implication to eliminating waste here. Everything that is not simple, is wasteful and deteriorates the process for maintenance. By focusing on simplicity, waste is eliminated by definition. Similarly, Cockburn separated Crystal into families of methodologies to keep them simple and eliminate methodology weight from smaller teams while still preserving necessary and relevant ceremony for larger teams. Crystal therefore eliminates waste by structure of the methodologies.

Build Quality in

Tackling the quality matter for the several Agile methodologies is a bit more demanding. First, test-driven development from XP is one of the most difficult Agile practices, but it is also the most copied one. Cockburn speaks about it for Crystal, similarly it is in wide-spread use in vital Scrum and Kanban practicing teams. The Pragmatic Programmers speak about quality from the start. Pair Programming from XP is a way to review code as you go. Likewise, customer involvement from XP together with specification workshops and specification by example bring in quality right from the start. These practices are in wide use among methodology boundaries and are shared in the whole Agile community.

Create insights

Personally, I rephrased this to “create insights” from “create knowledge”. The single-most Agile practice that everyone recommends is taking the time for reflection. There are several names for the same concept. Sprint Reviews in Scrum, Kaizen in Kanban, Retrospectives in XP, Reflection Workshops in Crystal all generate insights from a time-boxed interval of the project, and set the team up for knowledge from their past iterations or sprints. Over time, the team piles up more and more knowledge created from projects, tried out ideas to improve the process for themselves. “If you need to adopt just a single practice, use retrospectives, the rest will follow up.”

In addition to regular reflection, transparency is the key to visible progress. Information Radiators, Task Boards, Story Boards, build monitor are all ways to make progress visible among Agile teams. Combined with the insights and actions from the last retrospectives, they set the team up for success. Not only in Scrum and Kanban, but also for XP and Crystal.

Last, involvement of the customer from the start is a key success for visible progress. Showing results from the last work increment to the customers and stakeholders in regular intervals is a vital part of XP, Crystal, and Scrum. Getting the feedback from the people supporting the project also sets you up to build quality in.

Defer commitment

Similarly as the previous two points, deferring actions to the last responsible moment is a common theme across Agile methodologies. The principle is in play for programmers building the programs incrementally and iteratively, for iteration planning in XP and Scrum, and even for process improvement actions to foster.

But I recommend to take care here. “Defer commitment” does not mean in any way to not commit to anything at all. The team commits regularly to the next increment to the product they grow. The team calls this the iteration, the pulse at which Agile software development operates. Like a living system, the iteration is the heart of Agile development methodologies. Accompanied with reflection about the last pulse, the Agile development organism adapts to new situations and sets themselves up for the vital learning in the team. Crystal, XP, Scrum and Pragmatic Programming names this deferred commitment. It’s even a part of Software Craftsmanship, which I personally would include to the Agile methodologies – though they made a value-shift based on the initial manifesto.

Deliver fast

Here I also need to add a note: Don’t confuse speed with progress. Note the ambiguity for delivering fast. One way to deliver fast is to deliver at a high speed, while coding yourself into the corner of Technical Debt. This is not meant. Instead, you have to keep an eye on the delivery for today, but also set yourself up for tomorrows delivery. A sustaining pace is vital for todays fast – in terms of progress – delivery, and for tomorrow’s. This insight is at the heard of the Cooperative Game principle from Cockburn and underlying the Crystal methodologies.

In fact, one key motivation for the Software Craftsmanship movement at the end of 2008 was the realization that the “setting yourself up for the next round” became a common practice for fast delivering teams. The key is not to deliver fast today, but to deliver fast today, tomorrow, next week, next year, and even in ten years. Over the course of the last decade with the widespread of Agile methodology this seems to have been forgotten.

Back to methodologies, the iteration pulse in Scrum, XP, and Crystal creates the basis for the sustainable pace. The team sets themselves sets up for a continuous flow of value for customers and stakeholders. Thereby a steady flow of progress with indeed fast delivery is achieved.

Respect people

XP defines the XP team generating the respect for the people on the project. Similarly Crystal evolved out of the respect for people. Setting up self-responsible teams that take care and pride of their process for themselves, enables them to deliver steady value and – as a side-effect – increases productivity. Leaving people with the choice for their own process, getting them motivated to succeed the project, and rewarding them for their achievements is a core Agile aspect. And there is nothing more rewarding to show a working piece of software to your customer and get the appreciation from them – at the end of every second week or every month.

Optimize the whole

Reflection workshops take insights from the team and action items from good reflection workshops create an optimizing whole. Putting the people together in cross-functional teams, removal the boundaries from decades of separate working, enables everyone on the team to see the whole picture of the project. For example, planning poker puts together the whole team to work out the scope of the next increment. Specification workshops put business analysts, developers, and testers together with customers to get their needs and form a common understanding of the product to build. One key aspect of Crystal is the easy access to expert users among teams. Without this all encompassing view on the project as a whole, there wouldn’t be a way to optimize it as a whole. In companion with self-organizing teams, this optimization becomes natural in Agile projects.

Finally

One final point I would like to raise. Why does it matter for you to be Agile or agile? Instead of hunting for a place or time you may call “Agile”, rather ask yourself, “does it work for you?” If you can seriously without any doubts state, “yes, it works for me and all my colleagues, stakeholders and customers”, then you shouldn’t bother. If not, asking “are we agile” won’t help you either, since you don’t know if you need to be Agile in your situation, of if you should be somewhere else. Following a practice or notation just because it’s the latest hype, is cargo-culting. Instead you find out where you want to be, and plan to get there, but to set yourself up to anticipate any directional changes while trying to get there.