Managed failure is good!

One of the reasons why I like Agile development is because it enables the team to manage risk and uncertainty. It also allows a team to learn from earlier iterations and improve processes.

Reading the blog “Are You Squandering Your Intelligent Failures?” made me think how closely an executive approach to learning from failure is similar to the approach taken by Agile teams. It’s funny how I never really read about Agile projects that failed, unless you count London Heathrow Terminal 5. Oh! and Toyota - The Wrong Lessons From Toyota's Recalls — And the Truth.

Will there be a time when Agile projects become too process driven and people lose sight of the original purpose of Agile. Then like Toyota the problems start to creep in because nobody feels able/willing to hit the stop button.

To have done everything possible to prevent failure and fail shouldn’t be considered bad. To repeatedly fail because of the same problem is definitely bad. What does it mean to fail even when the processes should prevent failure?

Some random blogs

Very good explanation of why organisation blow their brains out trying to meet share price expectations - Why CEOs Don't Owe Shareholders a Return on Market Value  

It’s all too easy to forget simple rules about effective management, here is a reminder- Eight Things Your Employees Want From You

This is worth reading when considering innovation within your own organisation, just because it’s about starting your own business doesn’t mean it isn’t relevant to large organisations- The 2-Minute Opportunity Checklist for Entrepreneurs

Technology roadmap - engineer or manufacture?

In October 2009 I went to a talk on “Enterprise Design Objectives - Complexity and Change” where John Zachman gave a talk on his framework. John is a very charismatic character and I would say it is worth going to one of his talks.

There were several related topics during his talk that stuck in my mind(1) engineering or manufacturing, (2) ontology (3) late binding / loose coupling.  While John’s talk was specifically about Enterprise Architecture and not software development there are similarities.

The definition of engineer and manufacturer, as I recollect, were:

Engineer – builds primitive models and templates for mass produced solutions

Manufacturer – takes primitive model or template and produces the final product, “creates an instance of an engineered solution”.

As a small organisation it is important to identify the balance between engineering and manufacturing, don’t re-invent the wheel. A balance between engineering to achieve a competitive edge and using existing products to accelerate the manufacturing process has to be achieved.

Altio has spent many years of effort engineering a framework for implementing RIA applications using Java, as a small business this is costly and makes maintaining momentum difficult. That is why the focus of future Altio releases is now on engineering only the features that provide the greatest value to existing and future customers. As many features as possible will be implemented using high quality products from third party sources.

As an organisation Altio is changing the balance of development effort from engineering to manufacturing.

Capabilities

Identifying items to engineer and those that can be re-used as part of a manufacturing process is achieved by defining capabilities, how each capability relates to another, and the features of each capability. In effect defining an ontology for the framework.

During the talk on Enterprise Architecture a statement was made that it is impossible to engineer the enterprise, the answer to this was the Periodic Table, an ontology of atoms. Very complex structures can be created from basic, loosely coupled atoms, humans are probably the best example of this. This was the justification for defining Altio capabilities and features, thus enabling us to generate a product backlog to begin development.

The key to delivery will be ensuring each capability is loosely coupled thus enabling late binding of solutions and modular implementation of each capability.

The value add to our partners and customers will be knowledge, support and framework capabilities that accelerate the delivery of high quality solutions.

Reference

http://www.zachmaninternational.com/index.php/home-article/89#maincol

Where did the last few month go?

I can’t believe it’s 2010 and my last entry was in October.

I’ve been maxed out working on the future roadmap of the Altio and technology.

Altio 5.3 was released in September, and Altio 5.4 will come out before March this year. Altio 5.4 is likely to be the last major release of Altio using Java Applets for the front end. Altio 6 will retain the Presentation Server backend but the user interface is primarily going to be Adobe Flash, developed using Adobe Flex.

This means that for 2010 the toolset for user interface development using Altio will be Java Applets, Adobe Flex and HTML. The long term future will be HTML/JavaScript, but it will be a case of seeing where Google and other big players take HTML5.

The key changes to the Altio framework will be more attention on data visualisation for specific business domains such as Foreign Exchange trading and compliance.

I can’t see 2010 being any less challenging than 2009, and let’s face it life would be boring without challenges to overcome.

Interesting links

Explore the Semantic Web's standards and real-world applications

ScrumButs Are the Best Part of Scrum

How Will You Make a Difference in 2010?

Follow-up on duct tape programmers

Just read Beating the duct programmer with generic domains, subdomains, and core domains. Great explanation of when you want to apply software engineering and duct tape programming. As I’ve said before - there is a time and place for good software engineering and a time to just get the job done.

If only there were more duct tape programmers

Give me a pragmatic programmer any day, there is a time and a place for purists and perfectionism…normally when you have 20 million in the bank.

Please don’t get me wrong all teams need a balance of staff but when you are under pressure you need the guy willing throw the “design patterns” book away so the job can be done quickly.

Anyway, anyone who works with me will know how much I harp on about technical debt, well there is a great entry by Joel Spolsky called “The Duct Tape Programmer”. It’s not about technical debt but about developers who aren’t purists but certainly know how to get the job done, and understand the business need for getting it done as quickly as possible.

Go read The Duct Tape Programmer .

Technical debt doesn’t have to occur because of a rush job, it can happen through being too clever. If nobody else can understand your code unless they have a PhD in Astrophysics then you have technical debt.

Talking about must read articles I read Freakonomics this month, great book – made me laugh and go wow!

Technical Debt, JIRA, priority and severity

“efficiency is about doing things right, while effectiveness is about doing the right things”

JIRA is a great issue/task tracking system but I’m not convinced not having a severity field by default is a good idea, their explanation is;

“The Severity field was removed for a number of reasons, but principally because it was confusing to business users. To a software developer, it seems obvious that the severity of the bug ("The system crashes completely") is unrelated to the priority of it ("There is a one in a million chance of this occurring"). However, JIRA succeeds so well because business users can actually use it.  If you present a business user with these two fields, they are instantly confusing (which is why the Severity field was removed). “

This is a convincing argument. Although, I would suggest that not having severity over simplifies the decision making process. A decision probably best answered for each project individually – experience tells me the business is more inclined to be upset if they create a high severity record and the tech team mark it as low priority.

Decision making

As well as severity and priority should all projects now consider Technical Debt and Financial Cost associated with work items?

Managers require data to enable effective decision making, while a developer may perceive more fields as just being an additional overhead distracting them getting the job done. Technical staff need to be aware of the business benefits and costs of doing something. Spending days refactoring code because the coding standards are not met is not effective if a bug was never reported to do with the code. This is especially true when critical issues aren’t investigated.

I believe Priority, Severity are indicators of technical debt and time to resolve the task is the financial cost. Is it possible to put a value on technical debt? I’m not convinced there is, what I do know is that not paying it off early enough can be very, very expensive in the long term.

As a manager it is important to listen to a team concerned about issues in code and design, the team are responsible for effectively communicating their concerns.

Worthwhile reads – completely un-related  to this blog entry but got me thinking…..

The Kumbaya irony  - Are you having fun with technology for no apparent business reason.

What is Participative Leadership? – getting staff involved in making decisions.

Bibliography

Why doesn't JIRA have a Severity field like Bugzilla?

Technical debt

Finding the value in technical debt 

Refinance Your Technical Debt Just Like Your Mortgage

Paying Down Your Technical Debt

Technical Debt – great diagrams!

Your Greater-Than-Yourself Project

“Greater than Yourself”, is a great principle principle to have but I’m not convinced it can be achieved in isolation, unless you feel critical mass can be achieved.

Helping others to achieve their potential is something I’ve tried to apply in my working life, to varying degrees of success. The Harvard Business article “Your Greater-Than-Yourself Project” defines a concept to developing others and has certainly focused my mind on where I and others have done it well or poorly.

Whether you are an executive, team leader or junior in a team I think it is invaluable advise – I’m just not sure how easy it is to be completely selfless, especially when times are hard. A nice principle to aspire to.

The article states that the mentor should expect nothing in return, I have always believed that growing a network of successful people means that I can be more successful, so maybe I’m not entirely selfless.

References:

http://blogs.harvardbusiness.org/cs/2009/04/the_secret_of_great_mentors.html