At the beginning of his book, Allan Kelly describes Xanpan as both a method and a philosophy, his philosophy on how software is, or should be, created, and how Agile works, or should work. If Xanpan is basically a mix of XP (eXtreme programming) and Kanban, it contains ideas and techniques of other Agile and Lean approaches, focusing on how teams should work together to deliver better software and value.
The book explains how to apply the Xanpan principles and perspective on all the aspects of Agile software development like planning and estimating. It also proposes a set of technical and non-technical practices that should help teams. Xanpan also offers a tool to plan beyond the next two-week iteration, giving teams a perspective of what would be done in the next quarter and even further with roadmaps. One of the most interesting part of the book is the final appendix, where Allan Kelly discusses his own definition of software quality and presents the “quality onion”.
With his book Xanpan, Allan Kelly presents his own very personal and interesting perspective on Agile software development. This is a book that I will recommend to every ScrumMaster, Agile Coach or software developer that thinks that improving the software development process of a team is more about doing the right changes to the current process than blindly adopting a new approach.
Reference: Xanpan – Team Centric Agile Software, Allan Kelly, 200 pages, http://leanpub.com/xanpan
Quotes
Saying Xanpan is team centric also helps reconcile a conflict within Xanpan. On the one hand Xanpan is a process a team could pick up and use. On the other hand Xanpan aims to say “create your own process, don’t follow someone else’s prescription.” If the essence of Xanpan is the team then any team which setup and actively create and agree their own process can be said to be following Xanpan.
There is surely no team sport in which every player on the field is not accurately aware of the score at any and every moment of play. Yet in software development it is not uncommon to find team members who do not know the next deadline, or what their colleagues are doing. Nor is it uncommon to find managers who have no insight into the work coming their way, or indeed what happens to work when it leaves them.
For a strict Scrum team there is no issue of work carry-over, because teams only commit to work they guarantee will be done, and thus all work committed to is done. While many Scrum teams find carrying work over from sprint-to-sprint an anathema, I advise teams to carry over work. Indeed, carrying over work to improve flow is a central feature of Xanpan. For Xanpan teams work carry-over is a fact of life. As part of the review process preceding the planning meeting the team should look at the work remaining on the board from the closing iteration and decide which, if any, work will be carried over to the next iteration.
Almost every financial product in the UK comes with a warning: ‘Past performance is no indicator of future performance’, or words to that effect. Unlike in financial services, in software development the case is reversed: ‘Past performance is a good indicator of future performance’. That statement comes with a caveat of its own: ‘…provided nothing significant changes’. Work out what constitutes ‘significant’ for your team. Common examples include people leaving the team, the team expanding at an inappropriate pace, work streams changing direction or being disrupted, other resources suddenly becoming unavailable, and so on. This cuts both ways. If things aren’t going well, then no amount of positive thinking and leader exhortation will make things go right. Unless you do something to fix the problems you are finding, they won’t suddenly be fixed. Nor will they be fixed simply because you declare yourself to be doing Agile, Scrum, Xanpan or anything else. Equally, if things are going well, it is reasonable to expect them to continue to go well. Forecasts of future deliveries and schedules can be made with some degree of certainty – if you get the techniques right.
While much of the benefit from code reviews simply rests on having a second pair of eyes read the code, a second – but very valuable – benefit is knowledge-sharing and learning by the reviewed and the reviewer. Code reviews expose individuals to alternative practices and patterns and allow for discussion about better practices. Again, automated or electronically mediated reviews may hinder such discussion.