Agile Stance Series Part 9 - Prioritization

This is part 9 of the series of post around Agile.

Prioritisation

With the knowledge that the Sprint Team has a good understanding of the User Stories and with the estimates that the Sprint Team provided, the Product Owner is now fully able to prioritise the Product Backlog in 1 to x order, meaning that no two User Stories will have the same priority.

The Product Owner is warned that any User Stories with the same priority will be left to the Sprint Team to prioritise.

The Product Owner starts by selecting two User Stories and prioritising one above the other. The Product Owner will then select another User Story and insert it above, below or in-between the existing User Stories. The Product Owner will continue to do this until all the User Stories have been prioritised

Agile Stance Series Part 8 - Dependencies

This is part 8 of the series of post around Agile.

Dependencies

The Sprint Team would do well to note down any dependencies between User Stories while estimating and any dependencies between User Stories and external factors should there be any.

A dependency is a task that is required to be completed before another task can either be started or finished. An example of a task that must be completed before another task starts, a door must be opened before anything can pass through it. An example of a task that must be started before another task can start could be that you need to start charging your phone before you can use it, although the task of charging your phone doesn't need to be complete in order for you to use it.

Often there are multiple tasks that need to either be started or completed before successor tasks can start or finish. This as you can imagine can get very complicated and may require a system to manage and keep on top of.

There are a number of techniques to identify dependencies including work breakdown structures, but this post is to merely suggest that using an agile methodology still means that dependencies require attention.

Your bad habits make you stressed

I'm talking about the bad habit of not doing something that you should, rather than a bad habit of doing something, like eating food that is bad for you or smoking etc.
So with that in mind, read the title again and think about it for a moment!

No really, do!

"Your bad habits make you stressed".

As an every day example this could be as simple as, I don't like taking the rubbish out, so a bad habit might be that I don't take it out as often as I should. This causes me stress because of the knock on effects of having it indoors for too long.
Is this actually stress? Well, seeing the rubbish indoors brings on an emotion of "oh I must take the rubbish out" and "ffs, nobody else has taken the rubbish out" and escalates to an emotional outburst of "will one of you lazy *!#*# take the damn rubbish out"! So yes, in this instance, this equates to stress and could be combated by me performing the action of taking out the rubbish.

As a more complex example, think about the tasks you're involved with in your working life that you don't do as often as you maybe should, maybe because you don't like doing them, you don't think you're very good at doing them or tasks that are somewhere in-between. Does this sound about right? The simple answer is to get on and do these tasks and eventually you'll conquer them, but that's quite a jump from zero to a hundred.
Firstly you're going to need to identify these tasks, so make a list.
Once you have your list, go back to each list item and detail why that item needs to be done, what the benefits of doing it are and what the trigger should be for doing it.
The why and benefits should be your motivation and the trigger should be your prompt of when to do it.

We are all creatures of habit and most of us like routine of some sort or another be it big or small. We're content to be told what to do and when if we understand and agree with the reasons for doing the task and the gains of doing it (the why and benefits). What motivates us even more is if we are the one telling us to do it, as we like coming up with good ideas more than following other peoples good ideas!

The follow up to this post will be, "Other peoples bad habits make you stressed", but I will need to work out how to perform miracles (or at least put some more thought into the subject) before I can provide some substance on effectively combating that!

Right, off to put the rubbish out now!

Agile Stance Series Part 7 - Definition of Done

This is part 7 of the series of post around Agile.

Definition of Done

During the Sprint Planning the team will be brought together to agree on a common definition of what it means for a task to be done/complete.

It is important for the team to come to an agreement of what done means to them. Remember, agile is around buy-in and not dictation. The team should discuss and decide together what equates to "done".

The outcome will be a list of checks (not to be confused with formal project acceptance criteria) that a task must pass.

Depending on the types of tasks, this might be a separate list for each team or for the different types of work package or more commonly, a single list for the entire team.

The list could include:

• code written
• code peer reviewed
• unit tests complete
• documentation complete
• integrated with code base
• other checks specific to the environment

This puts an emphasis on producing quality and the teams buy-in and commitment to the Sprint Goal.

Agile Stance Series Part 6.5 - The Roles of Scrum

This is part 6.5 of the series of post around Agile.

The Roles of Scrum

I've realised that I'm focusing more on the Scrum Methodology than any of the others, so thought it wise to briefly outline the different roles.
Although I'm sure as a reader you're not taking this as your only source of information, for a more complete view of what I'm trying to achieve with this series I feel it is necessary to define these roles.

ScrumMaster
The ScrumMaster ensures that Scrum Methodology is followed. They mediate decisions between the team and help each of the team and the Product Owner perform their duties by removing what have been termed as blockers and providing clarity on how Scrum works.

Product Owner
The Product Owner is the conduit to the business. They have are effectively the client and where the requirements come from and sign off on deliverables come from.
This is arguably the most difficult role as the Product Owner is potentially a spokes person for a wider audience of different and potentially opposing views with a variety of goals.

Team Member
This is as you can imagine the team that will work to provide deliverables. In a software project, this will be made up of analysts, designers, developers, testers and depending on the nature of the project, probably more.

Agile Stance Series Part 6 - Estimation (2 of 2)

This is part 6 of the series of post around Agile.

Estimation (2 of 2)

Planning poker is an effective estimation aid that promotes a collaborative estimation consensus between the Sprint Team. The technique involves each member of the Sprint Team making 'silent bid' (estimate) using a playing card by placing it face down. By placing the card face down, each estimate is not influenced by any others. If all estimates are the same, a consensus has been reached. If there are differing estimates, this bring conversation on what people see as being involved in the task taking the team into a deep level of understanding and ironing out assumptions that have been made.

User Stories that that cannot be completed in a single Sprint, must be broken down into smaller manageable chunks. When the second User Story is selected for estimation, it is compared to the first. If it is twice as complex, it will be allocated twice as many Story Points. If it's half the complexity, it will be given half the amount of Story Points. If it is of a similar complexity, it will be given the same amount of Story Points. The key to this technique is maintaining a consistency and estimating each User Story consistently with the previous User Stories. Maintaining consistency will allow the measurement of velocity over several Sprints. Without this consistency, the value of velocity and forecasting are lost.

The estimation will be an estimate to complete the User Story in its entirety, including analysis, development, unit testing, integration testing and acceptance. This emphasizes the concept of multi-functional teams, where each of the Sprint Team member will be required to do more than just a single task, be that task analysis, development, testing or integration. The Sprint Team is a dynamic group of individuals that are able to support each other and handle a range of tasks and responsibilities.

Agile Stance Series Part 5 - Estimation (1 of 2)

This is part 5 of the series of post around Agile.

Estimation

Once User Story concepts have been listed, the sprint team will review the User Stories with the Product Owner present and ensure that they have a good understanding of what is involved with each User Story.

During this process of going through each User Story, the Sprint Team will make a points (Story Points) based estimate of the complexity for the User Story.

Story Points based estimation is a way to purify an estimate free of extras such as padding like contingency and other additional time added to tasks. A task is what it is and is rated by its complexity rather than the time it will take to complete.

The time to complete a set of User Stories will be reported on at the end of the Sprint giving the velocity of working for the Sprint Team. This also allows for team members of different skills levels to view User Stories with the same measurement. A User Story of complexity 5 story points to a senior team member will also be a complexity of 5 story points to a junior team member. This begs the question, what is the value of a Story Point!

The value of Story Points are relative to other User Stories completed within the same project, by the same Sprint Team. Estimation is begun with a single User Story. It is rated by its complexity by a measurement between specific parameters. This could be numbers for example 1 to 6, t-shirt sizes x-small to x-large or anything that the Sprint Team has a common understanding of and inspires them. The only rules are that largest complexity rating must be achievable within a single Sprint duration and must be collaboratively agreed to by the Sprint Team.

Agile Stance Series Part 4 - High Level Prioritization

This is part 4 of the series of post around Agile.

High Level Prioritisation

With larger Product Backlogs, it's generally good practice for the Product Owner to start prioritising at a high level.

This could be a "MoSCoW" (Must have, Should have, Could have and Won't have) approach or could be that the Product Owner just selects what stands out at them as the most important User Stories to begin with.

Either way, this ensures that the more important User Stories are addressed at first.

Prioritising is incredibly important part of the Agile process. Without prioritisation the team does not have direction, delivery is not clear and value of the product cannot be visualized.

Agile Stance Series Part 3 - Testing

This is part 2 of the series of post around Agile.

Testing

Is testing different for a User Story compared to a traditional project?

The User Story will need to pass each of the Acceptance Criteria in order to pass testing and Product Owner approval, also known as User Acceptance Testing (UAT).

System Testing

There will be different levels of Acceptance Criteria for each of these purposes, for example testing acceptance criteria will include low level detail such as when selecting a new username:

• the character limits must be adhered to
• case sensitivity rules
• special character usage restrictions
• backend checks to prevent possible duplicate with existing usernames
• calls to backend database
• data validation around characters sent   

User Acceptance Testing

UAT acceptance criteria will be more around whether the requirement meets the Product Owners expectation from their vision and the actual business need.

Agile Stance Series Part 2 - User Stories

This is part 2 of the series of post around Agile.

User Stories

Within a Scrum project, requirements are gathered for the project in the form of User Stories. A User Story is a concept for a requirement. A User Story is not meant to be a detailed document negating the need for any further communication, more so, a User Story is a talking point and placeholder for further information to be gathered.

A User Story is commonly written in the following form:

"As a {user type}, I want to be able to {action/goal}, so that {beneficiary's reason/value}".

For Example

"As a Manager, I want to be able to review actions made on a document, so that I can report  on the number of documents progressing between statuses".

This alone is not enough information to develop a requirement, but it is enough information to engage the product owner and learn more.

Each User Story will also have Acceptance Criteria associated with it, but that's another... story!

Agile Stance - A series of posts on Agile and Scrum

I'm going to write a series of posts around Agile and specifically Scrum and keep this page updated as a table of contents for all the posts in this series.

This is to help me aid and direct people for learning purposes and (to shamelessly use the pun), I'm going to keep the posts Agile and evolve them when and where necessary.

I'll start with a quick intro...

Agile is an approach that was originally created for software delivery and now widely used across a number of industries and in a blog I read a good while ago was used to effectively organise a family holiday.

It is an approach that uses iterations or cycles of a fixed amount of time to openly and clearly delivery a successful product rather than to just complete a project. This allows the product requirements to change during the course of the project (not the course of a iteration/cycle) to better align to the deliverable for success as opposed to not changing due to a locked down plan that leads to completing the project, albeit unsuccessfully.

Agile incorporates the ability to modify what is delivered without necessarily extending the duration, budget or scope (the three project constraints) of a project, but also does not necessarily prohibit the extension of one of these constraints.

Confusing?
Not really.

Simply put, if there is more work to complete because of our change, we could :

• extend the duration in order to get these changes incorporated in the product
• extend the cost by using additional resources to complete the change

Both of these would also extend the scope, because nothing was dropped from the scope to allow for the change.

• drop an item of equal effort to the change from the scope would allow the project to continue on track without extending budget, duration or scope

Does this sound like your corporations dream? Being able to change whatever they want when they want, even mid-project? Well, it's flexible, but not quite that simple, it requires discipline in using Agile, in fact it requires a few disciplines and for those disciplines to be understood and adhered to by a few different people too.

These are what I would like to cover over the next few months of posts...

Contents:

1. This one!
2. User Stories
3. Testing
4. High Level Prioritisation
5. Estimation (1 of 2)
6. Estimation (2 of 2)

Email Unsubscribing

http://www.roundpulse.com

I undertook a mission last month to unsubscribe from all the emails that I don't even read and just delete. I thought it would just be a couple of emails each day for a week or so to get rid of the bulk of them and then every now and then to remove the stragglers that don't get emailed to me too often.

Wrong! I am not 6 weeks into the exercise and still unsubscribing strong! While unsubscribing, I thought I saw a few emails that I'd unsubscribed from coming back, I dismissed it and thought that I must be mistaken. After a month I decided that I needed to track what I was unsubscribing from so that I could check to see who was not actually removing me from their lists.

I didn't want this to be a taxing task as I should have to do it at all, so I just created a Gmail label (a folder in any other email application would work just as well) and placed emails that I unsubscribed from under that label (in that folder) after unsubscribing. That folder is filling up and sadly the most repeats are from an organisation that I used to support through work reasons while I was a developer.

Why not just mark them as "Spam" I hear you say? Well, to me, spam is for emails that I shouldn't have received at all that an automated service marks as spam using its smarts. I don't want to add to my spam folder as I check it every now and then for false positives (emails mistakenly captured as spam), so I'd just be sweeping the issue under the carpet and still be pained by it when I checked for my false positives.

I foresaw this issue of receiving emails that I didn't really want a long time ago, I think about 10 years actually. I had purchased several domain names that in some way or another related to a project that I wanted to do or a company that I want to manage. I used one of these domain names to give out dummy email addresses, giving a different email address to everything and everyone that asked for email contact details from me. This way, if I was to receive an email from an unknown sender, it would allow me to see who I gave the email address to originally (details of how this works below). My thought was then that I would be able to just kill that email address if I didn't want to receive emails from that sender anymore.

Gmail has setup an option to do something similar, where you can tag some text onto the front of your email address followed by a plus "+" sign and then your actual Gmail address. For example randomTex+myEmailAddress@gmail.com. But I think most techies will catch onto this pretty quickly and it will be easy to write some code to just remove everything before the plus "+" sign and get around it.

Although a great idea, it got tedious as people would always ask why the strange email address. Of course the truth was that I had just made it up on the spot, but I didn't want to let on. It got a little tricky when they would ask me to repeat it, but luckily manageable. I kept up and keep up with this to a degree even now, but only when a shop asks for an email address or if I have to register for something online.

I could just put the second half of my plan into action and start killing off email addresses that I don't want to receive emails on anymore, but the problem is that I shouldn't have to and that gets me. So I'm trying the unsubscribing thing first and if that doesn't work, will have have to start killing the email addresses... sadly.

Now details on how the "giving a different email address" works as promised.

Purchase a domain name e.g. MyEmail.com. In the email settings of the domain name you can set up email addresses for your domain e.g. Bob@MyEmail.com, Fred@MyEmail.com etc.. No set up a "catch all" email recipient. That is an email address that will receive all emails sent to anything @MyEmail.com that isn't one of the specific ones that you've set up. Done! Now when you don't want emails to certain addresses at your @MyEmail.com domain, just specify them like you did with Bob and Fred above. Obviously, this will also allow you to see if someone (and who) has sold your email address off to a 3rd party.

Effects of Organisational Support Components of Virtual Project Teams

I attended a PMI Sydney Chapter Talk last night titled Effects of Organisational Support on Components of Virtual Project Teams and presented by Dr Nathalie Drouin. Nathalie is one of a team creating a research paper on this subject.

I collected a few sounds bites and caught a few interesting captions from the slides, but I feel that a little more depth into each of the bits that I caught would have been really beneficial.

"Competitive advantage gained by bringing together virtual teams." ND.

We each come from different cultures and I believe we all have something to learn from other cultures, from having a main meal in the middle of the day instead of the end of the day to hierarchical organisation structures and communications methods between those structures. I believe the learning that we can achieve from other cultures in a project environment would be worth a research paper in itself.

"Organisational relationships are getting more diverse" ND.

This is becoming more and more apparent, to the degree where in some organisations, being in a different department is akin to working for a different organisation with inter-departmental cross charging. Again, I believe this a a good subject and have noted it down to go into more detail in a future blog post.

"Even with virtual teams, group local team members together." ND.

This is most valuable advise. When working with virtual teams, having those teams locally separated can make them seem like multiple teams when trying to coordinate with them from a distance. Local teams having regular internal catch ups to assist the communication has much benefit. With distance can easily come confusion and any methods to reduce that confusion is worth pursuing.

"More frequent meeting with virtual teams". ND.

With a local team, you're likely to bump into team members around the office and the smallest exchanges of information passed on. This creates a relationship between team members and will enhance approach-ability. You may also walk past a team members desk and see they are free or they may reach out to you with a question that they hadn't got around to asking yet. Without this flexibility and unneeded scheduled connection, more regular scheduled connections need to be made. That's just one pro for more frequent meetings with virtual teams. Again, I can think of a list!

"Specify communication protocols". ND.

Yes? No, should communication protocols be specified for any project team? Maybe different protocol due to the visualization. Again, another interesting subject in itself. I find that communication protocols are defined and then refined over time, some people aren't phone people, some aren't instant messaging people and some are not email people. To add another level, some people use all of the above, but prioritise them differently!

I enjoyed the talk Nathalie, stirred lots of food for thought.

Agile Risk Management Talk by Rowan Bunning

I attended "Agile Risk Management" presented by Rowan Bunning last night. Got to say, very well done Rowan for stepping in at the last minute. And I really mean the last minute, the scheduled presenter pulled out due to being unwell 24hrs before the event and Rowan came to the rescue. Rowan had given the same presentation recently, but still, I thought it was really good going, especially as I think we were a tough audience!

I picked up some good sound bites throughout the presentation.

1) If you want no risk, do not projects! Balance risk versus reward.
2) You can't eliminate risk, but you can manage it intelligently.
3) Impact map lays out the who, how and what of impacts were trying to have, as a mind map.
4) Creating a "safe fail" environment with iterations. Using multiple iterations, refine failed iterations making future success.
5) Risk Categories, business, social, tech, cost of schedule.
6) Which of the risk categories is most important to you?
7) Risk Discovery map. Assumptions, concerns and open questions. Used to facilitate risk discovery.

Rowan did a good interactive exercise around Risk Categories, separating the ground into sections depending on which Risk Category they thought was the most important to us. Once separated, we had to pair up and discuss why we thought our Risk Category was the most important. It was a great way to get people interacting and actively thinking and by having people only pair with other of the same view, it wasn't going to raise too many heated debates to be broken up before Rowan could continue.

PMI Sydney Talk - Risk Energetics

I attended a very interesting and inspiring talk hosted by the PMI (Project Management Institute) on 19th September 2013. I would highly recommend anyone involved in project based work to attend future PMI events.

I captured a couple of quotes that were the highlights of the talk for me below, but to get the full environmental energy and experience you'll have to attend next time!

The event was titled "Risk Energetics" with the very well presented speaker Dr David Hillson. More information can be found on Dr Hillson's website - www.risk-doctor.com.

This quote is one of the more common excuses for not dealing with risk management.
"I'm too busy to worry about things that might not happen! I've got to deal with what is happening".
It's very much an argument we have when under pressure, should we have a reactive or proactive approach? I expect we can all related to this and the difficulties associated when in different situations.

"Ability to manage risk is the difference between success and failure."
You could loosen the terms and say that the ability to manage risk is the difference between being thorough and complete AND potentially recklessly gambling or fingers crossed hoping! But certainly as a responsible project manager, even if the risk never eventuates, if you've failed to manage that risk (document, measure impact and likelyhold, plan mitigation, monitor and release), you've failed to project manage properly.

"Identify and plan response stages of risk planning require creativity."
This was very interesting about keeping energy levels up, attention focused and enthusiasm during risk planning workshops. Risk planning requires creativity and creativity requires motivated participants.

This is gold and does not really require much explanation...
"Some projects moonwalk. To moonwalk is the appearance of moving forward when actually moving backwards".

Dr Hillson promoted this book "Ruth Murray Webster - facilitating risk meetings" and ran through a few themes of resistance to risk and techniques to combat them.

Energy Sappers
- Risk process takes time and money.
- responses cost money
- it's just scare mongering
- too busy
- too late, my risks are built in
- it's just common sense

Common themes for team not engaging in risk management
- disinterest
- distraction
- disillusioned

Common solutions to promote risk management engagement
- education/explain
- focus
- demonstrate value

What can be done to Maintain levels of energy throughout the project. Renewable risk energy. Breaks, demonstrated value, education.

I loved one of the final quotes from the talk.
"The beatings will continue until the moral changes...".

Another that I was not so keen on around implementing change and change management (and I believe there was more context around it) was.
"Change the people. If that doesn't work, change the people"!

Inspiring talk as always. I look forward to the next one.

Tagging Software

I was searching around the web for a Tagging Application.

What are Tags?

Tags are essentially unstructured labels, so like using a folder system where you can add a file to many folders and those folders don't have to be related. Imaging looking in your filing cabinet for your business insurance receipts (for example!). Do you look in your insurance folder, your receipts folder or your business folder. If you've put a copy of this document in each of the folders "Insurance", "Receipts" AND "Business", you could look in any of them and find it. Although tagging doesn't create copies, you can search for the tags and see all documents relating to the tag and if you're luck you could search for multiple tags and see only documents that relate to all the tags you searched for. This is how gmail works...

What I was wanting the application to do?

To allow me to easily find any of my documents that I may or may not have filed in logical folders. So when I want to remember what that thing was that I bought for my house last year was, all I have to do is search for the tags, 2012, house, receipts and if I'm lucky, I'll have remembered a few more details that I can search on to narrow the results a little further!

The three that I tried...

Elyse

This seemed like the most basic of the three applications. not very feature rich and no real interaction with the file system. To interact with any files, you have to import them into the Elyse database. Once in the database I'm sure you can do all sort with them, but how do you know what you haven't imported? You could be hyper organised and always import every file on creation, but in real life that's not going to happen and there is no margin for error. What happens if you keep all your files in one folder and you only add them to Elyse once a week... I have to be honest and say that as soon as I worked out this flaw, I uninstalled.

TaggedFrog

The Good:

• right click to add tags to files in window explorer
• progressive filtering

The Bad:

• no in application file system integration
• manual import of files into the application

My highlight for TaggedFrog was that I found that the search (internal database search) was good in that it was progressive, so you could select a tag, it would display all files with that tag and in the lower window pane show all tags from those documents. You could then select from one of those tags and it would reduce the number of documents filtering them out. So when I selected "2013" tag, it would show me all documents with that tag and all other tags that those selected documents had. I would then select one of those tags "Bank" and it would filter to only show me documents with both the "2013" and "Bank" tags. I could further filter. It's a quick and easy way to find what you want when you're not 100% sure where it is... So long as you tagged it right in the first place.
But, essentially TaggedFrog has the same problem as Elyse in that you don't know what you've not imported, but there is direct file system interaction as you can right click files in Explorer and add them to your TagFrog database. There is an AutoTagging feature, but it does nothing more than watch folders. So again, the not knowing what is in the database is a killer for me, uninstalled!

TaggTool

The Good:

• in application file system integration
• progressive filtering

The Bad:

• $9.99
• Immature interface

In the TagTool application, you can view your file system directory in a list format that will also show you what files have what tags. This is a quick and easy way to see what has not been tagged. For this reason alone TagTool comes out on top when comparing these three applications for me.
The interface is also quite nice and visual. As TaggedFrog, there is a similar system of progressive filtering, the only issue I have with this is that starting a new search should be down with the tags (as the search is tag driven) and it would be nice to always have a clear view or all tags in a left navigation bar and keep the filtered tags where they are. Also the recently used tags window should be expandable in height and lastly the file list window should have expandable columns. These are very little and minor things to make it more usable and easily forgivable if this was a free app, but at $9.99 and clauses against being entitled to major upgrades, it's not really very good. The interface is immature and at a guess I would say that the developers don't use this app themselves on a daily basis, which is a must for any application. But because of the file system integration, I will persist with the 30 day trial giving them opportunity to hook me in...

The Samsung Galaxy S4 Family

So nobody could have missed Samsung's new milestone phone the Galaxy S4. By all bar one account, in my opinion, a great phone and sadly, again in my opinion, a better phone than the HTC One, HTC's direct competition.

Samsung has used the framework of the SGS4 (Samsung Galaxy S4) to produce the: -

1. Active
2. Zoom
3. Mini

The Active being the indestructible* version, also waterproof. Size and specification the same. (*not really, but a lot closer than the others!).

The Zoom being a great step forward in direction of camera's. A wise step forward as smart phone users are taking cameras out less and less knowing that they're able to take fairly good snaps with their camera. I for one certainly would head to all socials armed with a compact camera to capture memories from the evening. In my opinion, the Zoom also is a good step towards being able to hold onto your smart phone properly, rather than balancing between a few fingers while taking self-ys, there is a nice big grip and front facing pictures using one hand can now be taken without worrying that the phone is going to slip and fall to its death.

Lastly the Mini. As I mentioned to start with the SGS4 is a great phone bar one feature in my opinion, it's too big! Don't get me wrong, I'm not keen on technology being so small that it's barely useable, but technology is not meant to get bigger in such a fashion that it impedes us, doesn't fit in our pockets comfortably, require two hands when they used to be fully operable with one hand and so on. The SGS4 Mini gets round this... to a degree...

So the SGS4 Mini is reduced to a dual core processor, obviously has a smaller screen with a reduced resolution, the FM Radio left out, touchWiz and a few other features rained in.

Other features removed are the split screen options which is a software change and not due to reduction in processor power as the SGS3 has a similar spec'ed processor and split screens very well. The removal of the indicator light. Some people hated it anyway, some people (myself) live by it as a power saving option, by not needing to power on the whole screen to check waiting notifications, but simply able to see what colour(s) the indicator light is flashing, which is also a lot quicker.

Second to last comment, dual sim on the 4G version of the SGS4 Mini would have been nice and tipped the balance enough for me to purchase.

And my last comment is that HTC have lost me as long as the battery isn't changeable (and SD card). They have assumed they know how we/I work and taken away the flexibility just like Apple did. The whole point of Android is that we like the adaptability and flexibility of our phones, please don't restrict them!

Watch this if you're thinking of buying a new computer monitor

Good detail to let you know what to go for when you're looking for a monitor to suit your needs.
http://www.lifehacker.com.au/2013/03/know-the-different-types-of-lcd-monitors-and-pick-the-best-one/

I attended a talk on Scrum last night

Sorry, very lazy, but only the Twitter highlights today. PS. It starts at the bottom!

1. Scrum presentation: Thank you Rowan. Very interesting presentation.
2. Sami Cox ‏@SamiCox21h

   Scrum presentation: Incremental approach gives greater visibility across projects to constantly assess their validity.
3. Sami Cox ‏@SamiCox21h

   Scrum presentation: Scrum Burn Down allows to see what has been done giving an actual status.
4. Sami Cox ‏@SamiCox21h

   Scrum presentation: Incremental approach allows to address release risk earlier.
5. Sami Cox ‏@SamiCox21h

   Scrum presentation: Incremental projects allow deferring of low priority features to less critical later stages.
6. Sami Cox ‏@SamiCox21h

   Scrum presentation: Incremental approach allows the evolution of vague ideas.
7. Sami Cox ‏@SamiCox21h

   Scrum presentation: Big Bang versus Incremental, ROI sooner with incremental. Quicker TTM (time to market).
8. Sami Cox ‏@SamiCox21h

   Scrum presentation: Small projects are simpler as the requirements are more set and there is greater certainty. Sprints maintain simplicity.
9. Sami Cox ‏@SamiCox21h

   Scrum presentation: The "Agile excuse", misuse of Agile eg. We're Agile so we went over budget. We're Agile so we went over schedule.
10. Sami Cox ‏@SamiCox21h

    Attending "Scrum: A framework for transforming your software project delivery capability" with speaker Rowan Bunning.

Attended a Webinar on How Businesses are using Cloud

I attended an interesting Webinar presented by Simon Elisha earlier.

I've posted some of the general highlights on Twitter @SamiCox, although I think the webinar should have really been titled "How Businesses can use Amazon Web Services as their Cloud Solution", but still there was some general information about what to look for in a cloud solution and I was pleased to have attended.

One question I would have liked to pose (but they ran out of time) was about migrating cloud services between providers, although I expect the answer would be yes between specific platforms for complete images otherwise import/export procedures, but would have been interesting to hear the answer from an Amazon Web Services point of view.

I'm on the look out for more online and preferably offline technology talks/presentations/seminars around Sydney, so please let me know if you hear of any.

Thought I'd post the tweets for the non-twiter-ers among you!

1. Sami Cox ‏@SamiCox

   How Businesses are using Cloud: Thank you Simon.

   Expand
   

   •  Reply 
   •  Delete 
   •  Favorite 
   •  More
2. 33mSami Cox ‏@SamiCox

   How Businesses are using Cloud: Risk: Your cloud data is partitioned so that it is completely separate. Further security could be encryption

   Expand
3. 37mSami Cox ‏@SamiCox

   How Businesses are using Cloud: Security: Just because something is kept in the cloud, doesn't mean that everyone can access it.

   Expand
4. 39mSami Cox ‏@SamiCox

   How Businesses using Cloud: Cloud service providers for eCommerce insist on PCI DSS (Payment Card Industry Data Security Standard) certified

   Expand
5. 43mSami Cox ‏@SamiCox

   How Businesses are using Cloud: Amazon Web Services, flexible in every aspect of scalability and option to be location specific.

   Expand
6. 46mSami Cox ‏@SamiCox

   Attending presentation on "How Businesses are using Cloud" with speaker Simon Elisha.