New Release for xProcess - feedback request

We're planning a new full release of xProcess in the next few weeks, which will incorporate all the features released in the beta versions last year and several additional fixes and changes. If you have any feedback from previous versions which have not been shared through the forums, or if you are able to download and run the latest source code version and provide feedback, please do so as soon as possible as such feedback is invaluable prior to the release. Thanks to all our users - we really appreciate your feedback and help.
To download the latest version use this link: https://sourceforge.net/projects/xprocess/.

The Last Shall be First - Continuous Delivery

One of the key lessons of agile processes is that the final step in your process - delivering software to your customers - is the first in importance. The best way to optimize the process is to work backwards compared to a traditional software lifecycle. When Dan Haywood and I laid out the outline of our "Better Software Faster" book, we decided to emphasis this by putting the chapter on build and deploy at the beginning - the first after the introduction. It's where agile teams should start in new projects or process transformations. Ensure that you can automatically build, deploy and deliver a tested change to your system, before you spend a great deal of time in building anything. If you don't do this you'll end up with a great deal of wasted effort further down the line, or worse still a waterfall process struggling to free itself from inappropriate practices and vaguely agile terminology!

The Seven Habits of Spectacularly Unsuccessful Executives

Eric Jackson

Eric Jackson's article for Forbes under this title is illuminating. I'm afraid it put me in mind of some CEO's I have worked with (and I hope there are enough of those over my long career in the business to keep the libel lawyers at bay!). More than anything I think the tendency - not just in CEOs of course - to attribute success simply to one's own genius / hard work / insight / inspiration, and all failures to the work of others, is the destructive habit I would pick over all others. When circumstances and good work conspire together to provide outstanding rewards, one does well to recognise that it is not simply one's own talent that has produced it. When CEOs and management boards believe all the success was down to them, their companies are in serious danger!

Kanban vs Scrum - less shootout more engagement needed!

David Anderson's book on Kanban provides a real insight into the practices and essentially the motivations for Kanban, particularly applied to process improvement. Since my reading happened to coincide with Ken Schwabers's dismissive posting about the method - saying that in contrast to the serious nature of Scrum it was a "nice distraction, for distracted people", it was helpful for me to look at all the examples, practices and theory in the book with as critical an eye as possible. I am a supporter of Scrum and believe it is the best starting point for team's starting out with a mandate to choose their process. However my recent clients have over 100 scrums working in parallel with a lot of other process surrounding them. They need methods for analyzing the waste in the processes and incrementally improving, based on sound metrics and evidence.

Kanban provides this kind of framework for improvement and I would strongly recommend such clients use it, as the basis for informed process development. As Henrik Kniberg points out in his companion volume to Anderson's, "Kanban and Scrum making the most of both", the methods are not incompatible. The fewer constraints that Kanban imposes on processes means that from a Scrum starting point, some of the constraints of scrum could be relaxed if benefit was deemed to flow from it. I presume this is why Schwaber objects to the method so strongly - if the starting point of the process is waterfall, one might end up with a slightly improved waterfall but not the major benefit that would flow from a true agile process. However if Kanban is followed effectively changes to a Scrum starting point would only be made if evidence was available for incremental improvements in the key business metrics. Yes there are risks involved in moving away from tried and tested agile processes. But that's where rewards lie too.

I'm not convinced by arguments between methods that focus on the character of those proposing them, when the substance of the methodologies are not examined. I expect more from the proponents in this case, more substance, evidence... and maybe a little more humility. Process improvement is not a one shot change from waterfall to agile. It requires insights from many different quarters to produce the best possible result for the business.

Why?

If you've not already picked up Simon Sinek's "Why?" video it's worth a watch. Thanks to Jean Tabaka for highlighting and expanding this thought in her presentation at GOTO Aarhus. Inspiring.

Google announces new programming language for the web at GOTO Aarhus

Gilad Bracha and Lars Bak, designers of Dart, Google's potential replacement for JavaScript, came on stage at GOTO Aarhus this morning both dressed as Darth Vader, proclaiming they had gone over to the Dart side. While replacing the lingua franca of the web is not going to happen any time soon (even in the opinion of these guys), the language does look interesting. It has optional strong typing claiming both the flexibility and ease of running of a language like Smalltalk, with type safety (to a point), modularity / team programming features and better code completion tools of languages like Java.

Interestingly the second presentation of the day was also from a Googler (Alex Russell) whose contention was that the problem for web developers was not the language (!) but the platform, with most of delays and impediments to powerful web programs coming from the need for network roundtrips.

Anyway, it's definitely worth taking a look at the early prototype release of Dart which is available here: http://www.dartlang.org/

Finding tasks in your Personal Planner

If you can't see the tasks you expect in xProcess Personal Planner check the filters. If all the boxes are unchecked, all tasks assigned to you should show up. You can then reduce the list shown using the filters.

Another thing that can make tasks harder to manage is if you are assigned to several projects. In this case consider using just one xProcess project and moving the other tasks to parent tasks with this project. The auto-scheduler in xProcess handles each project separately so if you are assigned to several you have to divide your availability between the projects first. On the other hand if you have just one xProcess project you can control the order in which the various parts of the work are schedule using priorites (see "Driven by priority").