Trusting a yellow sticky? Good luck with that.
At one point as our group dived into our particular miss-implementation of scrum we had, as you would expect, one wall of a meeting room covered in yellow sticky notes. And we’re not talking here about a poky little phone room. This was the room we used for “all hands” meetings and for team pizza lunches. You could fit a good twenty pizzas on that meeting table and still have room for drinks and garlic bread.
That wall and those post-it’s managed the work of twenty five developers. And as I was shortly to discover, it was the bane of our scrum master’s life.
One day I wandered in to see what my developers were up to. I only managed one of the four teams at that point in time and the wall was great to see what my guys were doing. M (I’ve abbreviated her name to protect her right to anonymity) was sitting at the table, and even my stunted geek emotional radar could tell that she was seconds away from bursting into tears.
She was in the process of reconciling the wall with the bug tracking system and the escalation system. This took an inordinate part of her day and to add insult to injury she’d just discovered fluttering around under the table like autumn leaves, a whole pile of orphan post-it’s.
So I grabbed my laptop, sat down and helped her sort through the mess. Then for the next few weeks we would spend a good hour each day keeping on top of everything. It was the end of the release and our director and his peers needed the bug and escalation systems to be correct.
Now you would have thought that we should have been able to rely on the developers and the QA’s to keep all the systems updated. But when, as a manger, you’ve got processes that require your developers to update three different systems when they fix a bug, you have to take some of the blame for the inevitable mistakes and oversights. Hence I was helping keep everything straight.
Not long after that we abandoned the wall and it’s plethora of fluttering yellow notes. And eventually we managed to merge the escalation and bug tracking systems as well. As a learning experience it taught me not only to choose my tools more carefully, but also not to blindly trust the crowd. At the time the web was abound with people waxing lyrically at how post-it’s had transformed their development processes and we’d bought into that.
To be fair, if you have no formal development process, no bug tracking system and no feature management system then post-it’s would be an improvement. But when you do have existing systems, introducing a new manual system that has no potential for integration with your existing systems doesn’t really make sense.
In an enterprise it’s important to be able to back up your assertions with hard numbers. VP’s like spreadsheets. During planning you need to be able to say things like;
“Based on the last three months of development my sprint team consumes an average of 23 story points per sprint, with a minimum of 18 and a maximum of 27. Feature ABC is 100 story points in total so it will take at least 4 sprints.”
That can be used in a planning exercise. Saying instead;
“I think ABC will take about two months.”
Is just inviting your VP to order you to do it in one.
When your data is in a structured system that keeps history around the epic user stories, the stories they were broken down into, the tasks they became, and the estimates at each step of the way, you have a corpus of data that cannot be argued with.
So what happens instead in the above scenario is that the conversation you have with the VP is directed to the feature set and what can be trimmed from that if a one month deliverable is a hard requirement for feature ABC. That is a more constructive outcome for everyone.
From previous posts you, dear reader, will have gleaned that I’m not an advocate of post-it based task boards. As a visual aid, and to motivate teams and provide accountability and visibility within the team they are great. But they are a one trick pony. You can’t usefully distill data from them for other purposes. You can’t integrate them with other systems, and you can’t see them unless you’re in the room.
Not to mention that post-it’s fall off the wall and get lost under the table.
Remote Working Shouldn’t be a Remote Possibility
One of my colleagues Anthony Langsworth has recently documented his experiences and opinions on remote working. He deals with it specifically from the perspective of an architect, an individual contributor, and I would agree with all the points he brings up.
Before I get to the purpose of this post I want to add that his point about video conferencing really resonated with me. A good setup, like the halo suite we had, can certainly substitute for many face to face meetings and could easily be used for a lot of scrum meetings. Unfortunately that kind of suite becomes a victim of it’s own success. Once our sales organisation became aware of how good the halo suite was, it was booked solid in that crucial two hour overlap that we had with the US office.
As Anthony says, try it yourself. I would add that if you can get a setup dedicated for your engineering department’s use, then by all means build processes around it, but don’t rely on it if you have to share.
But my purpose in this post is not to rail on about video conferencing. However it does introduce the idea of how, and in fact why you should incorporate remote workers into a scrum/agile team.
So why even bother?
There are several reasons why you should endeavour to include the facility for remote work in a scrum/agile team, or for that matter in any software development team.
The first reason to consider remote workers is that in enterprise scale organisations distributed teams are a fact of life. To get to the size they are most enterprise scale organisations grew with some level of merger/acquisition. That inevitably results in teams that are spread out over the country and indeed over the globe. In large organizations, outsourcing is a fact of life. So as an engineering director you will either inherit, or be required to develop, capability in India, China, Russia, or wherever else skilled labour can be had at a reasonable fraction of a US salary.
Even if you have all your engineers co-located, it’s inevitable that you yourself will probably report to someone on a different continent, or at least in a different timezone. You will also have shared engineering services like localisation, and architecture that you need to include in your processes. And let’s not forget technical technical support who will probably have some presence in at least three timezones.
So, if your development processes only support co-located contributors because they consist of sticky notes stuck to a meeting room wall, you are reducing your options for staffing, and excluding key contributors that make your product better.
The second reason to consider remote workers is that it gives you an edge in a competitive labour market. Unless you’re a merchant bank with deep pockets you can’t just buy the best developers. And if you want to keep your best people from being poached by organisations with more budget that you have, you have to change the game.
Usually in engineering organisations this is done by encouraging casual dress, having break rooms with X-Boxes etc. But working from home for one day a week is a privilege that is a lot more sticky. Not only can you equate it more easily to money, but once your staff have structured their family lives around it, they will think twice before taking a higher paid position at a much more conservative organisation like a bank. And sometimes that all you need to keep them.
I’m not suggesting that you should neglect your developer’s remuneration, but the harsh reality is that the only time in my career as a manager that I didn’t have to worry about competing with financial institutions for staff was during the first two years of the GFC.
The third reason to consider remote workers is because of a side effect that supporting them generates. Engineering is not only about engineers. You have to provide status up the management chain, and you need input from architecture, sales, support and product management. As I mentioned earlier in large enterprises you are unlikely to have all these on site. The more of your processes you can expose externally, the better your chances of getting the key people involved early. I’m not saying that everyone should see everything, what you expose is up to you. But if your processes are sticky notes on walls and you decide to email a daily scrum burn-down. Generating that e-mail will be a horrible, unreliable, manual process that will either send your scrum masters mad, postal, or more likely somewhere else.
What is the key enabler for remote workers?
Right, so you’ve seen the light and don’t want to rule out remote workers. You might have gleaned by now that I’m not a fan of post it notes on walls. As a way of introducing scrum, for small projects, and possibly in planning meetings, they are a fluid, tactile tool that encourages discussion. But for big ongoing projects you should use some kind of planning system like Version One, or X-Planner.
Your needs will vary, but as a bare minimum you should ensure that the system has the following features;
- Some kind of backlog for user stories and a way to break epic’s down into items that are consumable by your team/teams.
- Sprint task list management.
- A back end database, or accessible API’s
- (Optional) Automatic generation of basic status information like burn down and sprint summaries are useful both for yourself and your stakeholders.
The reality is that almost any system will hit this minimum list and in fact you will get a veritable plethora of additional stats and graphs and sprint planning, bug tracking etc. Before you start implementation ensure that it has sufficient API’s and hooks to integrate it with systems you have already in place that you don’t want, or can’t replace (e.g. bug tracking, or release planning).
The beauty of using an online system over sticky notes is that when a dev has competed their current task early (probably because they’re at home in a distraction free environment) they can log on and pick up another. Also, they can dial into the daily stand ups, and still get a sense of who is working on what. I have seen a junior dev pick up a task in a standup, only to have one of my principals chime in from the phone with an idea, or a request to review the code because they’re familiar with that particular area. They can do this when they have the task details in front of them.
Like bug tracking systems, and source code control systems, I consider an online backlog/sprint management system essential to the working of a well run software development team. And as long as it’s web accessible then your engineers and managers, who will be using it every day, can do so whether they’re at the office, at home, or on the road.
You’ll unshackle your developers from their desk’s, and you’ll get a number of other benefits as well, which I’ll go into in a later post.
NaNoWriMo 2011 Won!
A couple of weeks ago I wrote about my NaNoWriMo effort this year.
Well you’ll all be pleased to hear that I managed to win again. I passed 50,000 words with about three hours and fifteen minutes to spare, so it was a close thing.
Of course not everything went quite as planned. I’d hoped to finish the story a couple of days before the end of NaNo and then go back and fill in a couple of scenes to hit fifty thousand so I’d have a readable first draft on the 1st Dec. But as it was I lingered over the final chapter, it was enjoyable lingering, but it meant that I hit the magical fifty thousand in the penultimate scene.
So I still have a couple of thousand words to write to wrap it all up nicely.
Still, as an experiment to see if it’s possible to produce a readable first draft on the agressive nano schedule I’ll call it a success. And the beauty is that I can distribute this to a bunch of Beta readers and get feedback as to what needs work before I put a lot of editing in.
Assuming that is I have any Facebook friends left. Having only posted NaNo count’s for the last month will have driven some away I’m sure.
The Absentee Product Owner
I’ve said before that large enterprises are each unique and have situations that your typical scrum cookbook cannot anticipate. Because of their size enterprises tend to centralise specialist functions. Product Management is one such function.
Before I delve into the issues, I had better define what my company calls a product manager. You will hear names like; Product Manager, Program Manager, Project Manager, and Development Manager used differently even within software companies.
Product Managers are responsible for determining the product direction. They talk to customers to determine needs. They put together road maps and do competitive analysis. They work with sales to find out issues blocking adoption. They work with Engineering to produce product requirements, and determine priorities. I suppose you could say that they are the public face of the product.
That sounds like the definition of a product owner in scrum right?
Yes, and No. Yes they own the direction of the product, but they’re not part of the engineering organisation. At least in Symantec they’re not. They have their own VP who is a more or less a peer with the engineering VP’s who are ultimately responsible for the products they produce.
They’re also not a large group. There would be about one Product Manager for about every fifty developers. Because they need to spend a lot of time with customers, it makes sense to place them all together in whichever region has the most customers. And here is where I get to my point, in large outsourced organisations, that will probably be a different region to the development team.
For waterfall this doesn’t really pose a problem. Product Managers do a lot of travel, and getting them out to the dev team two or three times a year for a planning session works fine. Time those trips right and Development Managers and Program Managers can then run the plan through to release.
But Scrum requires a more week to week involvement from the Product Owner. Planning sessions at the start of each sprint, and handovers at a minimum. Regular backlog grooming needs to be factored in as well. Scrum pretty much assumes that you’ve got the product owner on hand.
Let me tell you right now that we never really solved this issue to my complete satisfaction. But there are some things you can do to mitigate the effects;
- Do not use paper based sprint tracking tools like post it notes or index cards. You need to move to an all electronic form of tracking. Use Wiki’s like Confluence (http://en.wikipedia.org/wiki/Confluence_%28software%29) and requirements tools like Version One or Feature Plan.
- If you’ve got high end video conferencing available, by all means try it.
- Once the backlog is all electronic, backlog grooming can be scheduled as a weekly con call between Development Directors, Architects and Product Managers.
- Do everything possible to get the Product Managers to attend sprint handover meetings via con-call. Handovers are more structured meetings with a fixed agenda and are easier to follow over the phone. They should be less than an hour, and make sure the QA lead prepares a demo and uses screen sharing technology like Webex.
Planning meetings are too long and unstructured for a Product Manager to add value on the phone. It’s possible to get Development Managers and Architects to act as a proxy for the Product Owners for the planning and operational aspects of a sprint as long as they’ve prepared in concert with the Product Managers.
Before I close I would like to make one more observation. Even though the best mapping to the scrum Product Owner seemed to be Product Managers, I’m still not convinced it was the right one in our case. In their role supporting sales, our Product Managers have never been as available to engineering as we felt they needed to be. Especially as in our case they were not co-located.
I find myself thinking back to the early Altiris days before we’d grown to the point where we needed a Product Management organisation. Our CTO, (later VP) performed that role, and did some coding occasionally as well. He was the very epitomisation of a scrum product owner. Unfortunately CTOs and VPs don’t scale. As their organisation grows they need to create a structure to delegate functions to, and unless that structure is created specifically with scrum or agile in mind we will always have this problem.
So be prepared to map the Product Owner role to several different people. And if you’re a Development Director one of those people will probably be you. Because as far as your VP is concerned you are the Product Owner.
NaNoWriMo 2011
Seeing as it’s half way through NaNoWriMo for 2011 I though I should do a post on it. Well, to be accurate it’s half way through and I’m still on target, which is the important bit.
This is my second year doing NaNo, I “won” it the first year I attempted in 2008 with a SF story that had been percolating in my head for a couple of years. I didn’t start in 2009 and 2010 mainly because I was traveling in November for both those years. If you don’t get off to a good start with NaNo on November the 1st, it is a struggle.
Others seem to see business travel as a good opportunity for time to write. On the face of it sitting in a lonely hotel, or more likely a lonely hotel bar, should be ideal for the creative process. Sequestering yourself works wonders. But despite my good intentions I never seem to get anything done when I’m traveling.
Not that I hadn’t been writing during 2009 and 2010. I’d added another sixty thousand words to the 2008 novel for starters. But those years just weren’t NaNo years.
This year however I decided that seeing as I knew I could do NaNo, I needed to up the ante.
First I decided that I’d step out of my science fiction comfort zone and instead write some literary fiction set in the present day. A character piece about a group of tango dancers who live in a small country town. Now I do know a little about tango, and I grew up in a small country town, so it’s not completely out of my comfort zone. And it’s also another one of these stories that’s been bouncing around for a couple of years. But still, it’s not Sci Fi.
Second I decided that instead of adopting the NaNo recommendation of turning off the spell checker, covering the backspace key and pumping words out (NaNo is about producing a first draft, not a readable first draft), I would actually attempt to not only hit the 1,667 word count target each day, but produce decent edited prose along the way.
This is turning out to be a more significant challenge. Not because the process it different, it’s actually closer to the way I would write outside of NaNo. But it’s tough to produce 1,667 edited words per day.
As I’m doing it I’m finding myself drawing parallels to the old statistic you’d have learnt years ago about programming. It goes, a programmer on average produces one hundred lines of code a day QA’d and delivered to a customer. Sure any decent programmer can type more than a hundred lines in probably forty five minutes if they’re in the zone. It’s getting it to a quality level the customer will accept that takes the time.
And that’s what NaNo’s like. It’s that forty five minutes of work that get’s you your hundred lines of code. And for discovering if you’re capable of writing a book it can’t be beat.
This time though my goal is to be able to give this book to my beta readers on December the first and not have them think I have the English skills of a nine year old.
So far I’m keeping up… just.
The B word
OK so you’ve seen the Google Ken Schwaber videos on http://video.google.com/videoplay?docid=-7230144396191025011 and you’ve sent your program managers and dev managers off to scrum training. And your whole team is full of enthusiasm for the new processes.
And they make a lot of sense. Taking a chunk of functionality and getting it to the point where it could actually go out the door is a good idea. Adding lots of half baked features just to show progress and then bug fixing in a death march for months or years is no-ones idea of fun.
So you vow that from now on features will not be released until they’re done, done and done. Technical debt will be a thing of the past.
But, there’s always a ‘but’. What about all that code you already have in your enterprise application. You’ve got –lets say– ten million lines of code developed over ten years. The quality of that code will likely be highly variable, depending on which developers coded it, who QA’d it, and what management pressure the team were under at the time.
You will in all likelihood have a bug list as long as your arm. There will also be customer and management escalations to deal with, if you haven’t got a good solid sustained engineering team covering your back (as I was). In fact if you’re strapped for resources your ability to get new functionality to market is probably groaning under the weight of just supporting what you have already.
The thing is, dealing with bugs is not something I’ve seen addressed in Agile/Scrum. Possibly because training and books seem to focus on small new development projects that don’t have this problem.
The first thing you need to do is get agreement from the product owners how much new development, vs technical dept, vs bug fixing you need to do. These will not be easy conversations. But if you focus on the customer benefits you should be able to come to an agreement on what percentage of your teams should be fixing bugs.
Second you should add bug fix items to the backlog, giving each one enough story points to be consumed by one team for one sprint. It’s important that these items are visible to everyone.
Thirdly you should schedule each of your sprint teams for a bug fix sprint on as fair a rotational basis as your critical path analysis will let you. Spread them out over your whole release cycle and if you have enough teams you should aim to always have one team on this duty at all times.
What you get from this approach:
- You’ve always got a go to team for escalations that you can hit up without frustrating them, or having them lose momentum on a feature.
- Having teams do nothing but bug fixing for two or three weeks give you good data on their fix rates.
- Once you have data you can predict ahead of time how many bugs your team will fix for a given level of resourcing. This will be invaluable when it comes to producing service packs. You will be able to use hard numbers when having conversations planning releases and how many bugs the business gets for what level of resourcing.
- Your teams are going to be a lot happier to do a bug fix sprint if it’s only every three or four sprints.
Things to watch out for:
- Don’t let your teams fall back into old habits. They should be fixing bugs that come up in sprints within that sprint, they should not be knowingly contributing to a net increase in bugs as features are implemented. Make one of your “Done, Done and Done” criteria a metric based off your bug tracking system and use that same system to track all sprint bugs.
- The bug fix sprints in the backlog will be the first in the firing line when a new feature has to be added to a release. You will just have to fight for these if you think it’s warranted. One thing that may help is putting a focus on the bug fix sprints e.g. performance or reliability. Choose areas that are known customer pain points for your sprints and you’ll get better buy in.
- Resist the urge to pick up a couple of extra “bits and pieces” in a bug fix sprint. It will dirty your metrics, and they team will work better if they’re all working on bugs together.
- Don’t over plan the bug fix sprints, and don’t make the team’s commit to a specific number of bugs. Make the team’s total (not individuals) part of the handover and openly discuss the count and how they compare to your other teams. That will generally be enough to spur them on to doing their best especially when they know that they (the team) is being compared against their peer teams.
Bug fixing is not one of the most pleasant aspects of software development. But when I implemented the above approach it became less of a thorn in my side. Sure, the teams didn’t love it when they were doing it, but once they’d got a couple of completely interruption free feature sprints they understood the value of it. And they loved the ten minutes planning meeting for those sprints.
It was good to have a team I could hit hit up for any escalations without the guilt of pulling them off a task. Plus, giving each dev in your org the opportunity to help their director out personally at some point, and getting the opportunity to personally and genuinely thank them for it has a value to morale that is incalculable.
Size really does make a difference
This post is about organising large teams, specifically large teams working on a single product. One of the defining characteristics of enterprises is their size and the development teams, and the products they work on, within such an organisation often share that. Our VP used to brag that he had five hundred and fifty people in his engineering organisation, five hundred and fifty one including him. And apart from a few PA’s for the directors, and a small IT team most of that count were developers, QAs or their managers.
In many cases the teams will be organised on functional lines and broken down until you get to a manageable size. In that case each team can use pretty traditional scrum methods with little trouble. They’ll each have a backlog, four or five developers, two or three QAs and they’ll run their sprints as a single team.
But what happens when the product is large and there are 25 developers and 15 QAs working on it? And here’s the crucial bit, any developer can (within reason) work on any part of the product. Teams aren’t divided functionally, nor are they broken up into front end, services, and DB teams, or any other arbitrary division of responsibility.
This pretty much describes my team, and before you denigrate that arrangement there are good reasons for it;
- You can bring more developers to bear on problem areas and new features and bring them to market sooner. i.e. you’re more agile.
- Product knowledge is spread throughout the whole group as opposed to being siloed in functional teams.
- Developers are more mobile within a team allowing them to find their own niche. And happy developers are productive developers.
- The team is more efficient. You don’t have one team cruising with an empty backlog doing priority 3 or 4 items while another is under the gun.
- A single backlog.
Now there are downsides as well, I won’t go into that now. however, with regards to scrum I was fairly sure that a single sprint team with forty members wasn’t going to work.
The solution was to break the team up into six smaller sprint teams with 4 or so developers and two or three QAs each. How we chose the makeup of those teams I’ll leave to a later post. In fact there are many aspects of this arrangement that warrant later posts. The immediate issue we had to solve however was scheduling.
Put simply, with a single product and a single backlog and a single product owner, no two sprint teams could have a planning meeting or a handover simultaneously.
Remember that we have six sprint teams in this scenario, and that a planning meeting is usually a half day event. Doing the math on a standard two week sprint that meant that the only time the product owner would have outside of the sprint process was Monday morning and Friday afternoon.
This is just one example of where slavish application to doctrine fails in the enterprise. Two week sprints are too short. So we made the sprints three weeks long. That meant that by staggering the start of the six teams, we could arrange two planning meetings and two handovers each week.
The reality is that most scrum advice says to start with 14 days, or 30 days and adjust the sprints to whatever works for your team and product. But the reality of our situation was that three week sprints were the only option we had if we wanted to keep a sustainable level of load on management.
So, where other teams might have stretched their sprint cycles out to deal with large or complex backlog items inherent to their product, we had to stick with three weeks. The reality was that often we would admit that some items were just not possible to implement in three weeks. Or, the effort to break them down into chunks that could be consumed by the teams in three weeks was not warranted or simply artificial.
So sometimes we broke the scrum rules about having artifacts of one sprint carry forward into another and having no concrete deliverables from the first sprint. I’m sure everyone in the enterprise has done it at some point. And as long as you can arrange things so that you don’t branch for release between the first and second sprint, where’s the harm.
Of course, when your fresh-out-of-certification-training scrum-master sees this happening you’ll catch an earful, but only the first time. Once you’ve broken another half dozen or so rules this one won’t even be a bump in the road.
Now, would I use that arrangement again? Only if the product can’t be broken along functional lines. It’s not easy. But if you have a big homogenous product and are short on staff it’s worth considering.
If you take this approach you need to consider the following;
- Scheduling is really important. You need to have your project managers create a schedule for your sprints and teams need to stick to it.
- Stagger the start of the sprints, and account for a dead couple of weeks at the beginning, and that you will have sprints still running when you hit milestones.
- If at all possible avoid Mondays for planning or handover meetings. Only because a public holiday will cause a reschedule, and this will invariable clash with one of the other teams and there will be flow on effects.
- Keep the backlog well groomed and the sizing estimates there normalised and reviewed. You will have enpough trouble tracking velocity metrics for all the teams without the additional complication of adjusting for backlog variance. (This is good advice for any backlog really).
- You will be have several backlog items consumed per week, so you need to keep ahead. Remember there are two planning meetings per week.
- Keep track of runs of related backlog items. If you have the runway on the project plan it’s better to have the same team pickup related items. It’s good to give teams choice and let them self organise the work, but that still needs oversight.
Setting the Stage for the Agile/Scrum Posts.
Technorati claim code (if you’re a human, ignore) 9ZS25592YUDK
This is the first post in a series about Agile/Scrum and how it fits into software development at the enterprise scale. Well, when I say series, there isn’t going to be a cogent sequence of articles that build on top of one another. This isn’t a recipe book for success. And that’s important to understand that up front because I don’t believe that you can provide a one size fits all solution at the enterprise level.
Because each enterprise has it’s own culture. And because enterprises are big, there’s incredible momentum against cultural change.
You may know your pigs from your chickens, have product owners on board, and keep the backlog groomed more meticulously than George Clooney. But if your VP is used to dictating when you release, and specifying what will be in it before you begin, you will have some work on your hands.
What I am not going to be writing about under this category is a generic ‘how to do agile’ guide. You can find lots of those online, and in various training courses. There’s also plenty of consultants who can come in and take you through the standard steps to implement Scrum or Agile. And, if you’re a small shop building customer websites, or you’re writing internally consumed software, that’s all you need.
However, if you have five hundred and fifty engineers distributed between APJ, India, Europe and the US, twenty million lines of code, product managers wanting new features, twelve years of technical debt and very high profile customers who can bring enormous pressure to bear on your boss’s, boss’s, boss’s, boss’s, boss; Cookie cutter approaches just don’t cut it.
And that’s what I mean by momentum. You often have to work around, or work within, the organisational and cultural constraints that exist at your organisation. What I’m hoping these posts will do is help you identify those constraints before you reach them. When and how, or even if, you’ll encounter the situations I describe will depend on your organisation.
Hence why I’m writing them in no particular order.
I hope that my experiences with my small thirty five man team inside the organisation I described above as it went through a number of VP’s and a variety of methodologies will save some of you from the traps we fell into, or at least allow you to fall into them with your eyes open.
Empty Coffee Cup reload.
After many years of neglect the old ECC site has been consigned to the recycle bin and I’m starting a new blog/site.
Why?
Firstly, The old site was looking desperately dated, and because it was all custom code I never, and I use that word accurately, updated it. It was an interesting exercise in templating at the time, but the reality is that as a platform wordpress is vastly superior for that kind of site. I’ll be going over the old content and some of it may find it’s way into this site, although not with that atrocious colour scheme.
Secondly, I’m coming to the end of my time at Computing Edge/Altiris/Symantec, it’s been eleven years, and I’d like to start writing about my upcoming projects and also my past experiences in software development.
What are those experiences? and what projects? Well 
stay tuned and see.
