Month: August 2009

Creating Business Impact

In Altnet conference, one of the discussions was around why we can’t tell business “this system is not working, we have pains with overtime and bad code”; “we should go agile” and “ship in small pieces”.
Proposing a new thing is hard for business to pick up and put into process. If they can’t see the benefit, they won’t believe us. Of course more importantly, we should believe in ourselves first.

If you are an idea person, it kills you more to have the same system/people not listening you…
If it is not working, you may listen to Fowler: “if you can’t change your organisation, change your organisation.”

However, this is my fifth company, and being confident about yourself gives the power to find a nice company in a few days/weeks; there are thousands of companies out there! Unfortunately, some of the companies did change after I have left. [Can’t they change when I was there? Should I be leaving to make a company change?]. I started to thinking that maybe I should be doing something more “effective, having more impact” for business so that they will listen, and take my offer into account. Eventually, I will feel happy and satisfied…

Just because of this reason, I was in training last week: Creating Business Impact.
It suggests a template:

1. Present Position:
[Don’t go straight into the problem. Do]
-Think about giving praise, thanks, and recognition, if appropriate
-Describe position now [e.g. sales, layout, staffing, system, equipment]

2. Problem
-Describe this so that the reader has a clear picture of what is happening, or could happen, if things don’t change.
-Stick to the facts, rather than your opinions which could differ from your reader’s.
-Don’t be too emotive -sound rational and reasonable.

3. Possibilities
– Set out different ways you could address the problem
-Number of ways. Give main advantages and disadvantages of each.
-Don’t confuse your reader with too many ideas, but you need to show you have thought beyond one solution, or one favourite brand.
-If you have a lot of facts and figures to present, put these in an appendix, and in a format that makes it easy for your reader to compare like with like.

4. Proposal
-State which possibility [or combination of possibilities] you recommend, and say why [without repeating all the advantages listed within the previous section]
-Anticipate likely objections, and address these.
-If possible, say how long it will take to get any return on expenditure.
-Say what happens next [i.e. Ask for finance, meeting].

That’s all…
Let’s see, if I can change my company this time [without leaving it]…

OpenSpaceCode review

This was my second time in OpenSpaceCode, and probably feels more confident about giving feedback and getting negatives and positives from those two.
Lots of positive feedbacks can be found on my previous blog;  however improvement starts with constructive feedback, where about I will to write now.
A. Collecting Offers:
1. Fact: Before the conference, MVC was twittered around, so there was a high expectation on it.
Opinion: We should be taking the risk to trade off a session and creating our own session.
Or maybe, we should be asking for volunteers to have sessions. [Did anyone complain about MVC session other than it was a bit fast?]
Or experienced people from old sessions maybe…
2. Fact: On the day, a stock of post-its and pens were given to everyone.
Opinion: Everyone holding a post it in their hand may not be an encouragement for everyone, since people offered sessions were the ones without post-its [maybe a psychological effect]
3. Fact: The number of people was more, but the subjects offered were more popular/general subjects.
Opinion: Last time, the offered subjects were too narrow, following the examples @adean opening speech. I find his words really influential. However, general subjects [generally a few subject on one big one [MVC and spark,] helped people to continue the discussions, and to be in the discussion.
Can’t be thankful enough to the number [46], since lots of knowledge and experience were on board.

B. Selection process
1. Fact: We did not categorize the offers into “difficulty” level, whereas in the first one we did.
Opinion: I think this was because we did not have many alternatives. But this should help people be aware of their “two hours” limit…
2. Fact: We voted for the most popular ones [same as first one].
Opinion: Makes it easy for people to change their session if they don’t the one they have.
3. Fact: Hosts are volunteered; they did not have to be the person who offered.
Opinion: Sessions missing the person who offered the subject sometimes suffered from “why we had this session”, but helped people to nativagate to any related subject they want to go on.
4. Fact: We removed the post-its and stick them onto the doors.
Opinion: Removing post-its from the wall posting to the doors is an agile thinking way I believe, and I like the flexibility. However, we can have bigger post-its, so that we can write host names on them as well.
5. Fact: Some sessions were the same as the old one:
Opinion: We should be asking/telling that we had a similar session last time, telling about benefits
6. Fact: We did not question/eliminate the offered subjects
Opinion: The session I was in was IoC, and it was a wonderful discussion. However, now I feel like it is more proper for an altnet topic…Maybe, the name “OpenSpaceCode” needs some filter on the subjects?

C. Sessions:
1. Fact: Wireless connection setup took some time.
Opinion: This could have been on main first room, at least a small demo, since the guide was a bit confusing…Instead of saying “create a new wireless network”, it could say “add a wireless network connection from wireless network connection properties”, easy?
Since each time, this event is welcoming more and more people, being more direct can help, and assuming next it can be another place…
1. Fact: For some sessions, installation was the session.
Opinion: Yes, it is a way of learning, but preparing yourself for the tool, and not being able to touch it makes you disappointed. To increase usability, an installation package [or a tool like hornget] can be useful.
If these sessions were hold monthly, then the group could benefit from the previous sessions
2. Fact: There was no PowerPoint.
Opinion: Loved the “sharing” and involving part.
3. Fact: The rules applied and there is no expectation from the sessions.
Opinion: This is sad. There was an ultimate goal, having checked the source code into google.code.
I would rather keep the pace slow and give a chance to at least two people checking the code in.
[Still not sure, if everyone knows that they a have Google code account or how to use it, [and yes they are developers, they are clever people…]]
4. Fact: Finding out what to build is hard.
Opinion: We can have volunteers to write some projects, or to search proper/alternative projects from openspace, so that we can start with that example, and modify it through our goal.
We can have a session/day for looking at openspace projects and discuss which ones can be useful…
And refactoring can be another session who wants to enjoy.

OpenSpaceCode and AltnetUK weekend

I had one of my best weekends so far, a weekend with wonderful .net developers. On Saturday, there was Openspace Coding Day and on Sunday
Alt.Net UK Conference. Grateful for EMC Cohango for hosting and Thoughtworks for Sunday lunch.

As open space coding day is supposed to be an unconference, there was no keynote speaker, no PowerPoint, and people were expected to offer a subject that is in their interest zone, without being an expert on it. The fundamental rules are:
– Whoever shows up is the right group
– Whatever happens is the only thing that could have
– Whenever it starts is the right time
– When it’s over, it’s over.

My choices were for IoC with MVC 2.0 for morning session, and MVC 2.0 with Spark for the afternoon session.

For IoC session, Autofac was the main subject to be discussed in the session, and discussed the benefit of IoC and why should we use?
After two hours, we could not find the reason that every project should use an IoC tool, i.e. Autofac, WindsorCastle, or Spring, or Unity; however we end up with lots of learning:
— As you apply the fundamental philosophy behind the loosely coupled components, you may not need a tool to take care of it.
— IoC and Dependency Injection are not the same thing.
— Once you register your container [at the start up of project], you don’t have register again.
— There are nice open source projects, i.e. an ecommerce project suteki you can check if you want to look at.
— There is a nice open source tool for easy installation of an open source project, hornget that I will try asap [after lots of praise].

MVC 2.0 and Spark session benefited from Jeremy’s inputs, and we followed ScottGu’s MVC 2.0 article and then spark was the popular view engine.

On AltnetUK day, I had “Software as Art” which forces me write another blog on that. The main discussion was around what makes it different software engineering process from an engineering process and art… My concern is I can’t see the design part, since if we are going to create artisan table, not an assembly line produced table; who is going to pay it, or how should we market it? [Yes, it will cost much more…]
Then, “What if your company renamed Waterfall as Agile?” was a discussion about why we should be using it, and if we have enough pain in the development process without being agile, how can we improve the process [without telling you are doing agile]. Nice inputs were
— If you can’t change your company, change your company by Fowler
— Don’t tell you want to do agile, do agile and tell them it is waterfall [start being agile].
— By picking up the most important parts first and delivering those parts will improve the process with small frequent shipments.
— Creating documents, reports won’t help software to be better! [believe in hearth]
— Lean Thinking is a nice to book to start thinking in agile…

Can’t finish without adding the idea of @serialseb: to rename altnet as alternative group, since we are all developers and we should be able to switch between languages/platforms [which should give us more power in terms of awarenes what we have and we are missing…]

All in all, it was wonderful as:

1. Sharing knowledge is helpful
— Looking into new technologies/tools expands your understanding, especially you are in a company does not use the latest technologies, and you are learning/trying them on your own…
— Any book/article you have to read gets high priority on your waiting list [or gets into your zone at least].
2. Sharing experience is priceless
— “How did your project fail?” is not a question everyone would share in your company, but here it starts discussions with twenty people with lots of feedback that you can take back.
— The pitfalls on software projects on a broader view, gives you more question to ask for your own project.
— There are always gaps to improve, and this kind of activities let you see the gap! [Rest depends on you]
3. Hearing other people’s questions/worries on a subject makes it more interesting and you start to question in a deeper philosophical sense.
4. Have the chance to meet and discuss with the people that you follow their blogs, i.e. @JeremySkinner,@serialseb, @gojkoadzic and their inputs were incredibly useful for both days.