Things you do when your UAT is running TOO well

I spent the last week running around and sorting out about a million little things around an infrastructure which was supposedly ready for us to use (I bet that sounds familiar ;) ).

My name is Eduard
My look-alike

Thankfully I have a very creative team around me and they disguised my prolonged absence well whenever nervous stakeholders showed up begging for comfort. I am still a bit hurt that they keep saying that my look-alike is way funnier than I am so when there was nothing left to do - as much as the UAT group is trying to break the system they haven’t managed to raise anything yet - it was my time to seek revenge!

Instead of a boring day with nothing to do I challenged them to build me a Google-style interface for one of the components that we had built. A 5min brief and a few bullet points on the white board later they were off doing there thing. To make things interesting the challenge was limited to 3 hours after which the testers had to have accepted the solution - i.e. it shouldn’t have any outstanding defects unless agreed with the sponsor (that’s me).

While it is a fun way to be productive when there is nothing else to do it also has an educational benefit. When you are working with a team that is relatively new to agile projects and the continuous testing paradigm a challenge like is a great way to see how they apply what they have learned so far. Every bullet point was treated as a feature and to give the testers enough time to go through and accept the solution (not to mention the inevitable feedback loop to fix defects or other observations) each of these features had to be deployed into a test environment as quickly as possible (continuous delivery). Otherwise it is just like an old-fashioned waterfall-style project with a very short test phase … and the common problems that come with it. At the end of the day I was grinning like a proud daddy :)

Fostering creativity

Imagine a bunch of highly talented people, all with different skill sets and maybe even from different industries and or social backgrounds. That’s a great first step towards a “think tank”, a creative environment where outside-the-box ideas can be bounced off each other and eventually morph into something very useful - be it for an organisation or even for the greater good of society.

Where it becomes tricky is when these people are not constantly co-located. After all creativity lives from spontaneous ideas and the longer it takes to discuss such an idea the more likely the initial enthusiasm and spirit has been lost. To make a think tank work in such an environment I believe we need something like instant messaging - but better! A way for members of such a group to communicate with each other as simple and as instant as possible but considering the individual circumstances.

Here is my list of requirements:

  • I need something that actively pushes messages from this group to my desktop - which could be at home, at work, on my phone or anywhere else in the world at any given time - i.e. I do not want to have a client installed on my desktop.
  • I need to be able to respond to the group at a time suitable to me
  • At the same token I believe that quick turn-around time of feedback on ideas is quintessential for creativity so I need to be notified almost instantly even if I choose to respond at a more convenient time
  • The trail of thought should be easily visible

These are the options I can think of right now (if you have another option please post a comment!):

  • Email/Mailing list: This is probably the most obvious technology. With web-based interfaces to your email account or services like gmail information is accessible anywhere and comes to me. It is reliable but not necessarily instant (depending on how often you check your mails). Mailing lists (e.g. Google groups) have an advantage over standard email in terms of user administration and have the option to be visible in web searches.
  • Forums: Currently a quite popular way to exchange thoughts and information on specific subjects. The main drawback here is that I would have to actively seek out information - i.e. I have to check the forums regularly and it would certainly not be anywhere near real-time.
  • RSS feed: Information comes to me but I have no simple way of responding. Just as with email there could be a bit of a lag before messages show up in my RSS reader.
  • Instant messaging: Most IM systems allow”conference chats” so it would be easy to include all members of the group. Except that one has to signed in (even if not currently at a computer) to see messages. It is also harder to retain information exchange from previous sessions.
  • Phone calls/video conference: While certainly the most effective form of communication (other than sitting down together) it has to be arranged and does not leave members with the required flexibility of schedule. A great option for catch-ups and discussions once an idea gets past a certain point but no substitute for what I am looking for.

From all these options mailing lists seem to be the best option. Mayday however (not surprisingly) has come up with yet another approach. Using one of the many Web 2.0 services freely available they trial a Twitter group, essentially using Twitter’s open API and Jazzy Chad’s extension. The main advantage here is that individuals can choose how to receive information (any one or more of Email, IM, SMS (Text), Web or a locally installed desktop client). Providing an SMS option extends your notification option suddenly beyond computer access (even if you can’t reply by text just yet).

The two drawbacks are currently:

  1. Messages are limited to Twitter’s 140 character limit (but multiple messages are of course ok)
  2. Posting to the group is currently restricted to TwitterGroup’s web interface

Personally I think the first drawback is neglible. The second one is more serious and I am eager to hear more about their experiences with this trial!

An Agile university

Ok, I know a lot of you guys out there are getting asked about certifications and education and all that sort of stuff and without it you face questions about whether or not agile is legit. Lean back and relax now and let the Agile University come to your rescue :) !

FLASHBACK!!!

Have you ever noticed that whenever somebody does a background research on you and googles you there is always the odd surprise? In my case the search apparently returned a bunch of really REALLY old newsgroup posts (back from the days where blogs didn’t exist i.e. last millenium) and this: the viennesestylescientists website.

I vividly remember putting this site together with Chiaradina back in 3 days and nights of sweating (literally, it had 35 degrees) blood (figure of speech) and tears (of laughter). In today’s usability driven world it probably won’t help my street credit as a web designer :) … but I still look at it and think “awesome work” - if you take the time to explore the site and find the hidden gems ;).
It’s really REALLY slow though - which I assume is because we have not paid for the webspace or the domain in at least 6 years. When we built this site back in 2000 it was designed for Netscape 4 and Macromedia Flash 4 (and yes it was still Macromedia back then) was state of the art :)

So I guess in this day and age you cannot escape your past “achievements”. What has the Internet’s resident memory on you?

Making money - the Web 2.0 style

I know I know - Web 2.0 is so last year and we’re already on the verge of 3.0 etc BUT I currently see first hand how Chiaradina uses it effectively to promote her message to a huge audience! She is one of the very few remaining contestants in iYomu’s 1 Million Dollar Challenge (think of the TV show Survivor on the Internet). iYomu is one of the social networking sites around and apparently chose to spend investors’ money to provide incentive for their users to go out and attract more and more users. To win this challenge she needs to have the most supporters voting for her every week.

By creating videos to spread the word and attract people to vote for her we have spent the weekend doing all sorts of very 2.0 stuff - including our very first YouTube videos - and may I say we had heaps of fun :)! Have a look at this:

The idea obviously is to create funny videos that people like to send on or re-post - and thus make her cause visible to people we could have never reached otherwise. So let me reinforce my message from my previous post and say: When you think about Marketing and your service offering - think Web 2.0!

One last word: Should Chiaradina win a significant amount will go to charity and there is a draw for 3x 10,000 USD amongst the people supporting her. So her gain could be yours and definitely a gain for charity - so do take 5min out of your busy schedule and sign up to vote for her ;)

Strategies of adopting agile in your organization

Are you thinking about adopting agile practices in your organization? Then you probably think about how you get on with it and what the best approach is for your particular organization. Top-down or bottom-up - should you start with the executive management or the people doing the ground work? Should you introduce it step by step or with a big bang (a la Salesforce.com)?

Mike Cohn has written up an excellent article about the pros and cons of several approaches. You can check it out here!

The 7 habits of highly effective IT projects

Funny - I was so sure I won’t prepare a presentation for the agile barcamp tomorrow but instead just talk straight from the heart. Yet here I am writing down my thoughts of how to best communicate the benefits of both an agile approach to software development but also to project management. So without further ado and in reminiscence of the 7 habits of highly effective people here are the 7 habits of highly effective IT projects:

Habit #1 - Open and trusting culture

I said it before and I say it again: Agile is a state of mind more than anything! Establishing a culture based on openness, honesty, trust and respect encourages efficient communication. Risk and issues are identified and brought to the table where they then can be resolved in collaboration. Goals, risk and outcomes are shared and the team (client and vendor, business and IT) works together to achieve the desired outputs. Individuals embrace responsibility and accountability for their actions and for the success of the project.

Habit #2 - Identify your stakeholders

Find out who your stakeholders are and divide them into three categories:

  • The ones that can stop the project - typically your project sponsor but there may be more
  • The ones that can delay your project - dependencies to other people/projects, political agendas etc
  • The ones that are interested in your project - they need/should be kept in the loop but do not have the power to impact the project

Failing to engage critical stakeholders from the get go can result in incomplete requirements, a wrong impression of the desired project outcome. Which leads us directly to

Habit #3 - Define success

Ask yourself if you have a clear definition of what success for your project looks like. Sure, there are the obvious things like “on budget/on time/to scope” but can you honestly say that even if you achieve all that your project is successful? What if you deliver everything but it turns out that the scope defined does not fit (anymore) the business requirements? On the other hand what if you do not deliver everything you set out to do but what you deliver is meeting the business needs perfectly?

At Fronde we usually define success with the help of sliders (developed by Rob Thomsett). These sliders show the priorities and the flexibility in certain areas, namely:

  • Stakeholder satisfaction: How important is it that all stakeholders are completely satisfied.
  • Objectives: Do all objectives have to be met?
  • Time: How rigid are the timelines?
  • Budget: Is there room for movement under the right conditions?
  • Added value: Typically not all objectives add equally value to the business (e.g. compliance requirements)
  • Quality: Does the system have to be bullet-proof? Or is there room for defects in lesser used parts of the system?
  • Team satisfaction: How important is it to keep the team happy (disgruntled team members might leave)?

The kind of questions that the sliders ask are along the lines of “Is it more important to meet the dead line or to add value to the business?”. Having all stakeholders agree on the priorities and movement in areas is a sure sign of a highly effective project!

Habit #4 - Define scope

Quite often projects define scope as business requirements - in other words features of the system to be built. Effective project management defines scope as explicitly in scope and explicitly out of scope. Everything that needs to happen to make this project successful but is not the responsibility of the project team has to be identified (typical examples are user documentation, training, implementation/roll-out etc). Equally important is to identify one or more stakeholders responsible for making sure these things happen! So every out of scope item has to have a name next to it and this person/these persons take on the responsibility of making it happen (directly or indirectly).

And by the way, once you have defined scope make sure that you manage it efficiently!

Habit #5 - Deliver often and early

Agile comes in many flavors but all of them rely on iterative development techniques. Short (1-4 weeks), time-boxed iterations provide well-defined milestones where small chunks of the overall system are delivered - fully tested and ready for a production release if the business decides so.

The progress reported to the business and end users is quite tangible and stirs thought processes about how fit the current system (built to the current specifications) is for its purpose and gives all stakeholders a chance to rethink the priorities of the features yet to come. Some features may get deferred or dropped at all in an effort to work to an ever changing market - some may just get dropped because they seemed to be a good idea at that time but with a tangible system in front of stakeholders lost their initial charm. New features have a chance to be implemented quickly because the business can prioritize them in at the beginning of each iteration.

Deviations from the intention of a requirement (e.g. a misinterpretation or ambiguities in the specifications) are discovered early on and can be remedied with little cost involved.

Habit #6 - Planning and tracking

Keeping habit #5 in mind there are basically two levels of planning:

  1. The project plan: This is the obvious one that most if not all projects have. It defines an overall timeline, major milestones and the road map - the strategic direction of a project or product. This is also the one that is more likely to adapt throughout the project.
  2. The iteration plan: Most agile methodologies recommend a half day to a day planning session at the beginning of an iteration. The key here is to break down the features/user stories/use cases into small chunks of work (1-2 days max). This will allow you to track progress in a much more meaningful way. Rather than estimating a task to be 40%/70%/90% completed (and run in surprises in the “last” 10%) a task is either done or not - and with “done” I mean it has been accepted by the testers. On a related note consider spending some time at the beginning of your planning session on a retrospective of the previous iteration.

You can track progress in many ways - e.g. using spreadsheets, web tools or sticky notes. Whatever you use make sure it is visible to the team and ideally the stakeholders. If you are co-located having a board with sticky notes that move from “open” to “in progress” to “in test” to “done” is an easy way to track and communicate progress.

Habit #7 - Tools

Make sure you have the right tools in place to support an agile environment! For a software development project for example, at the bare minimum have an IDE with productivity support (e.g. Refactoring toolset), a source control system that allows you to easily roll back to previous versions and a continuous build server that compiles the code and runs unit tests and some code analysis tools on each check-in. There is no point in embracing change when it takes you ages to execute the change and you live in constant fear of breaking something!