Tuesday, 19 August 2014

7 Signs Your Company is Agile

The Agile methodology (www.agilemanifesto.org) very clearly focusses on producing customer-ready software in the shortest possible time.  Almost every software development company these days seems to claim to be ‘Agile’, but what does it mean to truly be ‘Agile’?  

Here is a checklist to determine if your organization is in fact, Agile.



Cross-Functional, Self-Managed Teams

Developing software cannot be done in a silo; it takes different people with different skill sets working together to get the job done.  Whether business or technical, front-end or back-end, developer or tester, all roles are required to get your software to your customers.  A stream-lined process has all these people working together on a piece of software until it is ready to be delivered to the customer.  Team members need to feel free to voice their opinion, and provide corrective criticism.  There is no ‘leader’ of the team, just team members with varying skills, jobs, and experience.

Backlog

The Backlog is an ever-present list of features and / or tasks that are prioritized by management or company executives.  This serves as the basis for what the teams will be doing in each Iteration.  If you do not have a Backlog, your company is not ‘Agile’.

Acceptance Criteria

In order to meet the small time intervals with customer-ready quality, each item in the Backlog MUST contain Acceptance Criteria.  This ensures that all stakeholders are informed on what the tasks are, and what the software will need to do.  Without this, Developers don't know what to produce, Testers don't know what to test, and therefore work estimates cannot be given with any degree of accuracy.  If the items in your Iteration do not have Acceptance Criteria, your company is not ‘Agile’. 

Backlog Grooming

Backlog Grooming is vital to the success of the team, and is very commonly overlooked.  This is where the team reviews the next several items in the Backlog, ensures that they contain adequate Acceptance Criteria, and provides an estimate as to the complexity or effort of work that the Backlog items will take.  If you are not regularly grooming your Backlog or tasks are being worked on without Acceptance Criteria or estimated effort, your company is not ‘Agile’.

Iteration / Sprint Planning

The ideology of Agile Software Development is to deliver quality, customer-ready software in short time periods (called Iterations).  Iteration Planning is where the team accepts the top-ranking items from the Backlog, and commits to finishing them within the time frame of the Iteration.  Each Iteration is different (given holidays, vacations, etc.), so this step is crucial to ensure the team is not over-burdened, or under utilized.  If you are not planning each Iteration, your company is not ‘Agile’.

Continuous Integration

If you work in groups of people, and in time blocks called ‘Iterations’, does that mean your company is Agile? in small time intervals.  At the end of any of these intervals, the produced deliverables can (and should be) reviewed with all Stakeholders (yes, even the customer).  If this is not being done, your company is not ‘Agile’. 

Iteration / Sprint Retrospective

Any functional relationship must consist of some self-analysis, and and Agile Development Team is no different.  Regular analysis and correction is vital to ensure that all people have a voice, and constant improvements to the team are put in place.  If your team is not conducting regular retrospective meetings, your company is not ‘Agile’.


Wednesday, 19 March 2014

How to Start Working From Home

We have all heard the benefits of working from home (http://www.forbes.com/sites/kevinkruse/2012/12/18/benefits-working-from-home/).  But as an employee, how do you start the process of making it happen? 

The working from home relationship requires a great deal of trust from a Management perspective.  Management likes to see people physically sitting at their desks.  Having people working from home is a perceived loss of control.  So, it is up to the employee to make sure that working from home is not a negative experience for Management.


Make sure the company infrastructure supports remote connectivity
You need to be at least as productive from home as you are at the office.  If there are any applications, servers, databases, etc. that you cannot connect to from home, this will deter Management from allowing working from home.  This may entail having someone at the office set up a VPN (Virtual Private Network), but it will be worth it.  If you are unsure about the tools you need to access, try connecting from home at night.  Make sure you do some work where the timestamp is noticeable (i.e. sending E-mails), so they know you are working from home.  It doesn’t hurt to let people know that you accomplished work from home.  Plus, showing that you did some work on your own time from home shows great initiative.
Have a good reason
At first, working from home may be a no-go for your Management.  So, ease them into it by having a good reason that requires you to be home.  This can be days which you are sick (and not wanting to spread your illness around the office), to sick children, etc.  The choice for Management will then be to have you home and completely unproductive (like having to take a sick day), or home and working.  I’m sure they’ll choose to have you home and working.  Once they know that you are able to be productive from home (see point #1), it may be a good idea to leave this choice up to them initially.  Tell them that you have an appointment, so you will not be able to make it to the office.  Subtly hint that you are able to get work done outside of the time that you are unavailable.
Be reachable
It is vital that the office be able to get a hold of you when they expect you to be working.  If you get a reputation for not being available, you will not be permitted to work from home.  That said, If you know that you are going to be unavailable for some time, let them know ahead of time.  This shows that you are responsible for managing your time.  Also, some people like working ‘off-hours’.  9-5 doesn’t work for some people, and as long as you are getting your work done, then it shouldn’t matter when you do it.  If you are the type of person who wants to start work early and end work early, then make sure this is openly discussed and acceptable with everyone up front.  Instant messaging is a great way to communicate as easily as if you are in the same office.  So, make sure that you always have your Status set to ‘Online’ or ‘Available’, and answer text messages, instant messages, and E-mails as promptly as possible.  If it will take some time to put an answer together, simply send a response saying that you are working on it, and will get back to them shortly.
Be productive
You need to be at least as productive at home as you are at the office.  It is up to you to make sure that your work is done at least as quickly as when you are at the office.  To that end, make sure to remove distractions, or remove yourself from distractions that cannot be moved.  When I started working from home, I had to set up my home office in the basement.  When my kids saw that I was downstairs working, they left me alone (as much as kids can).  I also started ignoring the home phone as well.  If it was an important call, they’ll leave a message.

Initially, the amount of work you get done will be under scrutiny by Management.  They prefer to have people in their chairs where they can be monitored, so make sure your work gets done on time.  This may require more hours spent working initially (specially if you are working from home with sick kids), but the initial effort is worth it.    

Not only do you need to be productive, but the people you work with and for  need to know that as well.  When I commute, I tend to leave my computer in the bag when I get home, and it stays there until I go the office the next day.  When I work from home, the laptop is always there, open, and I am far more likely to pick it up once the kids go to bed to finish what I am working on.  I like to share that story around the office as an example as to how I am more productive from home.
Have support
If you are living with someone, they need to be on board with what it takes to work from home as well.  I am incredibly lucky to be married to someone who understands that working from home is still working, and that work that doesn’t get done during the day needs to be done at night or on weekends.  Also, she helps keeps the distractions to a minimum (reminding the kids that I am working, etc.).  Not only does she help with distractions, my wife also keeps me in check.  She is always asking if I had time to get work done, and makes sure that I know if I need time to get stuff done, she has no problem with that.  Working from home does have the added advantage of being able to help with the kids, as well as have lunch and coffee with my family, so there is net benefit for us all.
Expand gradually
Once you have laid out the ground-work and worked from home due to unavoidable circumstances, this can be expanded to days that you have appointments, or to avoid being stuck in traffic due to bad weather, etc.  Depending on your circumstances, you can even argue that you are more productive if you work from home on a regular basis.  I have a one hour commute (one way) from home to the office, so this is an easy argument to make.  I started by working from home every Friday.  After a while, I changed that to also include Mondays.

Randy May
Blaazin Software

Tuesday, 15 October 2013

The Human Side of Software Development

I am a Software Developer, new business owner, and a bit of a quiet person. During the course of my career, I have come to realize that it is not enough to just write great software. In order to be seen and recognized, it is vital to be heard as well. Some may call it schmoozing, or even bragging, but - in order to expand your profile - you need to be vocal and visible as well. 

Many times I have left it to Team Leads or Middle Management to send the communication to Upper Management or the Client. This is their responsibility after all, right?  I didn't want to step on any toes, or make anyone angry. 

The problem with that approach is that my own visibility was almost non-existent. Sure, my Managers and fellow teammates were very pleased with my performance, but outside of them, I was a ghost.

Since I started my new position at my current place of employment, I have taken a completely different approach. No longer am I the quiet one at the back of the room who keeps my opinions to myself. I now actively seek out and participate in meetings with Upper Management, Clients, and Vendors. I will make my thoughts and feelings known (with the utmost professionalism), and be the first person to send the message on new features, enhancements, and problems.

Could this cause problems? Could being vocal or having and communicating an opinion possibly lead to some negativity? It is possible, but I will remember that a turtle makes progress ONLY when it sticks its neck out.

#SoftwareDevelopment #BeVocal #BusinessPractices#ProfessionalDevelopment #CareerEnhancement
#PersonalDevelopment

http://www.blaazinsoftware.com

Saturday, 17 August 2013

Avoid Process Bottlenecks!

Don't let your processes interfere too much with the speed of Development.

Processes are vital to the success of any Software Development team.  Most development tools even allow for restrictions to be placed in them to enforce workflows, practices, policies, etc.  I once worked at a company that had their Issue Tracking software (JIRA in this case) configured to an 18-stage workflow process from the time an issue was opened to the time it was closed.  Even worse than having 18 stages, several of those steps could only be processed by 1 person.  If that person was busy, sick, or away for some other reason, the issue could not progress.  

It is not surprising that this causes headaches.  When the process stops (for whatever reason), the people involved do not.  Worst case scenario is that they have to chase down the person they are looking for.  Alternatively, they move onto other things (sometimes work related, sometimes not) which leads to more tasks being worked on at the same time.  At first glance, this may sound like a good thing.  After all, work is still getting done, right?  That may be true, but this leads to other complications.  As any juggler knows, the more items you have in play at any one time increases the possibility of a disaster.  An interrupted task is estimated to take twice as long and contain twice as many errors as uninterrupted tasks (Czerwinski, 2004).  

In an Agile work environment, the speed of development and quality of the software are paramount.  So, put checks and balances into place to ensure software quality (preferably automated), and review any and all processes to allow for the software to be built as quickly as possible.  Time is money, so wasted time is wasted money! 

Randy May
Software Consultant

Tuesday, 30 July 2013

How Much Business Training for Software Developers?

How much do Software Developers need to understand the business of the application they are developing?

Management and Business People tend to think big-picture (and that is a good thing).  They view the application as a growing (hopefully) number of services to a set of customers making the customers' lives easier, and ultimately making the company money.  Without question, this view of the application is crucial to the success of the application.  Without this view, the services that are built may not fit together, may not be complete, or may be missing altogether.

So, how much of the underlying business do Developers really need to understand?  How much time (and therefore money) should be spent on training Developers on what the application ultimately does?

When a Developer is building one of the above-mentioned services, they do not look at it as a piece of a larger number of services which form the application; they look at it in terms of what pieces of information are moving, what processing should be applied, and where that information should go.  Depending on the nature of the data, this could be a database, a call to another system, mathematical processing, etc.

To Software Developers, an application is just an endless paddle-ball game of requests and data processing.  The request comes in from the User, some data gets processed, and is then retured and displayed to the User.  Request comes in, data goes out; request comes in, data goes out, request comes in...  You get the idea.  An application is a series of data requests, API calls, reads / writes to a database, display of data to a User, etc.  

Remember, the same Developer can work on software that governs the fuel flow of a rocket one day, quantity of jeans on store shelves the next day, and a patient medication system the following day.  Do they need to be a PHD in rocket phycics, Masters in Business, have their MD?

As a Manager, you want top notch Software Developers that can write great code with few issues as quickly as possible - regardless of what business you are working in.  It is extremely beneficial that those Developers can transfer their skills from one subject matter to another; quality code is needed in rocket physics, retail, health care, etc.  Taking time to train Developers on the business of the application is ultimately wasted time, and time is money.  

You may be thinking that a Developer who has been with a company working on the same application for a long time is a benefit because they get to know the application and business the longer they work there.  What is actually happening is they are remembering the application, not understanding the business.  They will remember the services they worked on but that does not mean they understand the business.  Plus, the longer a Developer is in the same place, they run the risk of having their skills become stale.  Technology is moving at such an increasing rate that a Developer that is not moving forward is really moving backwards.

So, if you have a new Developer that has just joined your team, get them pair-programming with an existing Developer, and get them into the code as quickly as possible.  They do not need days or weeks of training to get them understanding the business.  They already know code; don't get in their way.