1. Supremacy of authority or rule as exercised by a sovereign or sovereign state.
2. Royal rank, authority, or power.
3. Complete independence and self-government.
4. A territory existing as an independent state.
5. A group or body of persons or a state having sovereign authority.

Take a look at the list below;

• Disconnect between the business and IT
• Distrusting environments
• Lack of genuine team empowerment
• Poor Product Management

If you do suffer with any of the points above I would like to introduce you to a new concept of creating a Sovereign Team or  Sovereign Teams. Recently I was reading an article by Mitchell Baker (CEO Mozilla) and she touched on User Sovereignty, this inspired me to think about Team Sovereignty.

A Sovereign team is in control of its own destiny, it operates with complete autonomy with the ability to control its destiny. Along with the these benefits also comes responsibility and ultimately accountability.

History shows that a good Sovereign leader listens to their people, just like how a team should listen to their customers.

Taking a pragmatic view, your business isn't going to change overnight, if they are distrusting today it is highly unlikely that they will be trusting tomorrow. Instead of trying to win the war, choose 1 of your teams to act as a Soveriegn team and get business buy-in that the Sovereign team you have is trusted and empowered to make the right decisions. Choose your team wisely, as this team could be the make or break of the opinion of the business towards your department. If it works, create more Sovereign teams, until all of your teams are Sovereign teams.

A word to the wise, as you create Sovereign teams it is highly likely you will encounter individuals who are 'letting the side down', I don't believe the team should call them out (no 'team' leaves anyone behind and encouraging call outs will create a negative culture within the team) so make sure that the line manager of the team members is on board with dealing with 'problematic' team members. Remember any Agile team is only as good as its team members.

An example would be stopping at a petrol station, asking the kids what they would like to snack on and then not being able to find the chosen snack for one of our children. At this moment the simple selection of a snack for our children becomes a nightmare when faced with the selection of 30+ choices of chocolate. Which snack do I buy? What type of chocolate is closest to the one requested? How big is the requested snack? etc... My partner will openly say that she would prefer to have a limited choice in which too choose from for our children.

Without upsetting my other half on her ability to make choices, I'd like to ask the question; Is an infinite choice select really best for your PO / PM? Or is it better to limit the options available for selection? As a team how much time is wasted defining stories for 30 chocolate bars (package design, chocolate content, etc...)? Is it prudent to limit the amount of choices available?

When I'm working with newly formed teams who have no Agile / Scrum experience I explain to them that the Product Backlog is like a wish list, so technically you could create a story that  puts a pig on the moon. As a team progresses you quickly realise that creating 'pointless' stories has a cost; excessive backlog grooming. Create a intelligent, realistic deliverable / achievable product backlog, one that doesn't take excessive time to manage. I always advise teams to keep 'just enough' user stories in the Product Backlog, enough for selection by the PM / PO and enough for the team to barter with.

Originally I was going to blog about our journey / experiences soon after we returned, but instead of getting caught up in the romance of the holiday, I thought I would instead get back into normality and then blog about Dubai.

The shortest summary I could give is that Dubai is that it is a wonderful place, the people, the culture, the hotels, my family and I fell in love with it. We were luckily enough to stay in the amazing Palm Atlantis hotel, its arguably the best family luxury hotel around, it offers a range of adult entertainment (if you like shopping stay @ the palm) to swimming with Dolphins. Its not cheap, but its worth every penny.

As for main street Dubai, we found the people incredibly friendly and the most child orientated society we have came across. Often I feel we misunderstand the middle east, often being led to believe that their culture is seriously oppressive and unfair to women, I can say that this is not the case. There are differences between how men and women are treated. Women obviously have to remain more covered up then us chaps and finances are looked after by the men, on the other hand women are served before men in a que and are expected to be provide any of their needs. Like all societies there are also edge cases and extremes, but there is a lot in the UK we could learn from the society in the UAE.

I certainly have a different view of the middle-east since going to Dubai, it is a country I and the family could go and happily live in.

This makes a lot of sense, particularly to fellow Agile people, breaking things down into simple, manageable chunks, I myself someone who preaches this often to my teams. It also supports my theory on having presenting too much choice - Is limiting what my partner can buy a bad thing?, but there are a lot of products that need an extensive choice array? How would you scale this up? Before I continue, this is more than likely obvious to those working on large scale computer games.

Heston and Ramsey have missed a trick, instead of having only one team of chefs, have more than one team making food and therefore increase your selection choice.

Upon a recent family holiday to The Palm Atlantis in Dubai I watched as one of the restaurants produce an enormous array of great food. In contrast to the meal I had at Heston's diner, though the food was good (equal not superior to the restaurant the Palm Atlantis), the menu choice was very limited by comparison.

What does this have to do with Agile you may ask? You can work on a large amount of features as long as you have multiple Scrum teams. Scaling up Scrum is not that hard, nor that difficult, but often scares new Scrum Masters when faced with Scaling up Scrum.

Back to my original point, maybe Ramsey / Heston should come and visit a scaled up Scrum model and then we could show them how to have a large array of options.

This post is contradicted though in my post; Is limiting what my partner can buy a bad thing?

Eddie was the head of IT at Girlguiding UK. Eddie helped me in numerous ways; as a mentor, as a leader, a motivator and a boss. Eddie is one of the most talented individuals around, though he wouldn't say it of himself, Eddie is a great person, not only professionally but also as a friend.

I've been meaning to post this blog for sometime, sadly I missed his leaving drinks due to other commitments but I would like to think one day that I would have the opportunity again to call him 'boss'.

I will shortly be pushing out a milestone deploy. The update is a data read-only version that isn't to far off being a MVP.

On a less than perfect note, I have put on hold the story that the site will support clientside IndexedDB support. Instead I shall move forward the story that allows you to use the following RDBMs;

• SQL Server
• Oracle
• MySql

I will at a later date add support for IndexedDB, but at present the documentation is flaky at best and I want a ratified standard to develop on for future support reasons.

I've already identified 1 issue, which is historical data capture of when sprints are assigned to a release and if this changes. I'll be including a data structure diagram with the code base, which will also include data types, relationships, keys, etc... please let me know if you see anything else I need to fix (I'm sure there is, I have become tunnel visioned )

At a major junction I thought I would update everyone of the really simple Agile tool.

• GUI - 60% complete
• Application - 10% complete
• Database - 5% complete

The GUI work is going better than expected, though there is some refactoring of the JS for neatness reasons. The biggest issue has been the way to handle offline storage. I had just implemented some basic Web SQL (SQLite) code, but as some of you may or may not know this has been removed from the W3C specification in favour of IndexedDB.... argh... I'd just got my head around SQLite through JS. It hasn't been helped that the examples for IndexedDB are absolutely shocking, to the point I nearly removed one of the really simple Agile tool's major features; offline storage. Step in http://greenido.wordpress.com/2011/11/29/convert-your-websql-to-indexeddb/ the only working example of IndexedDB, this has been the reason why offline storage is still one of the main features of the really simple Agile tool .

I'm hoping that I'll have the really simple Agile tool's backlog visible through the actual tool within the next 2 months (I'm cheating by pre-loading in JSON files that contain the state of the project, you'll be free at this point to do the same, but I would not advise it as it will not support updating features; it'll be read-only)

Github source: https://github.com/cbruiners/A-really-simple-Agile-tool