Improving your software development process

Some would not be surprised to hear that even as a developer I was always looking to do the least amount possible to deliver the goal of what I was working on – ie. I was always looking at ways to maximise my effort by trying my best not to do the same thing twice and would pull my hair out (look at my picture) trying to see if I could automate what I was doing.

As a manager this deep sense has grown into a desire to incorporate some of the core practices below that I feel epitomize a good development team and should be in a Technology Manager’s arsenal.

• Refactoring as you develop
• Drive for automated regression testing
• Automate your builds – Continuous Integration
• Industrialise your build process
• Agile Development Practices

These of course are not goals in and of themselves as they deliver monetary and time efficiencies due to:

• Lower development costs
• Lower maintenance costs
• Faster time to market
• Higher quality code
• The deliverable is more adaptable to changes that may arise

Refactoring as you develop

“Leave things better than you found them” is the old adage. In code we instinctively know that without refactoring, the design of the program will decay over time and that poorly designed code usually takes more code and time to get it to do the same things.

It’s often the case that on returning to code that we or others had previously written it could take a while to understand the functional design. One way of helping that is to refactor the code where needed to help familiarise ourselves with the code.

As managers we should be aware and genuinely concerned with quality as the lack of it usually comes back to bite us sooner than we think. We should not be obsessed with refactoring but should encourage it in our teams as on-going practice as they work.

Drive for Automated Regression Testing

We’ve all experienced it when a fix for something on our coding projects ends up breaking another part of the project. Automated regression testing is our insurance policy against this. As managers, if we are inheriting an existing project that lacks this insurance policy, we should require the development of an automation suite of tests that start off by testing our ‘egg on face’ key functionalities that we build on over time. If we are starting off on a new project that it should we should encourage that each business functional story should have automated tests that test their acceptance criteria. I know the above is a rather simplistic view of testing but this blog is only meant to be a summary of the key processes I think improve a software development team.

Having this approach to testing means that; developers spend less time bug fixing especially into the late hours of the night after a major release, managers push out better quality products that have had their risks identified earlier with less screaming customers, testers end up testing things once and not spending the majority of their time and company money on manual drudge work.

There are many tools and frameworks out there now to enable this to happen such as:

• Selenium
• Canoo WebTest
• JUnitPerf
• JMeter
• JBehave
• Cucumber
• Concordion
• FitNesse
• HttpUnit

And many more…

Automated Builds

Continuous Integration is the practice of automatically triggering a code build and running of unit and regression tests whenever a change is made to the code base. This provides instant feedback to developers and helps to keep the code base always close to a ‘ready to release’ state. Build problems are caught earlier, either by the builds failing or the tests.

Most development teams don’t automate their release process as it seems such a huge task to do and lack at times their managers support to do it. I would advise from experience that this is such a huge time saving exercise and is worth every penny. At one organisation that I pushed for the implementation of this, our build process to go into an environment could take upwards of a week. After implementing this the build took a few minutes!

This is now a normal and fundamental practice amongst many agile development teams now and reaps benefits such as; accelerated code release time, improved build quality, elimination of dependency on key personnel etc…

A good book for this is Continuous Integration – Steve Matyas and Andrew Glover

Industrialise Build Process

I’ve separated this from the above Continuous Integreation as Continuous Delivery (Jez Humble & David Farley book), an Industrialised Build Process, deals more holistically with the build, deploy, test and release process. For me it is reaching that peaceful state of knowing that you can rebuild any server in your development or release environments at the click of a button because your server configuration scripts and tests, in version control, are being kept upto date regularly.

Benefits are that our development teams and their processes are so streamlined that there are no pieces of infrastructure lying around whose configuration is unknown or hidden in someone’s head that has probably left the organisation! When problems like this occur, with no configuration scripts, it can cause significant downtime with added stress and effort to fix.

Added benefit is knowing that your tests are consistently testing against the same configuration of environment as the same configuration scripts have created them. If tests pass in the Test environment they should pass in Pre-Production, UAT and Production, making for a smoother deployment and maintenance process to live.

Agile Development Practices

A research report published by Forrester in May 2010 showed that agile is becoming mainstream. A total of 35 percent of surveyed organizations described their primary development method as agile. Moreover, 11 percent said Scrum was the most popular agile development approach. In another survey, Forrester examined the level of agile adoption and found that 39 percent of the surveyed organizations considered their implementation mature.

I’m not going to argue the pro’s and cons of Agile vs Waterfall here but suffice it to say that for most, if not all projects, I have come across agile development practices have been successful in their delivery. The greatest ideological differences for me are that Waterfall assumes that it is possible to have a near perfect understanding of the requirements before you begin while Agile embraces the reality that things change. 

So with Agile small teams work together with the real stakeholders to define quick prototypes or proofs of concept to explain the problem to be solved. The team then defines the requirements with the stakeholder for the whole project at hand but then agree to bite of a small working deliverable set of features in a short cycle – iteration. Work on this iteration begins and at the end the stakeholder is shown the results and a further iteration is discussed, according to the current requirements, to continue to deliver the whole with a subsequent iteration.  

With Agile customer satisfaction is the primary measure of success rather than performance to plan but there is still a plan and planning. This is split out over the Release Planning, Iteration planning and daily stand ups. This makes for a high-speed development schedule that can only succeed when coupled with the automated process discussed above.

There are clear processes in Agile for it to work and succeed, for example, users must review and approve changes before they are merged into the baseline code, developers must review each other’s code and code must be unit tested and have good test coverage. These process though give greater freedom to development within a light-handed enforcement framework that is inductive of success.

For more on Agile check out the Agile Manifesto and the Agile Alliance.

Conductor, Visionary and Cheerleader - Part 2: Visionary

Without doubt some of the key traits of a software development management, CTO or CIO
are that of:

• Conductor

• Visionary

• Cheerleader

Proverbs 29:18 - Where there is no vision, the people perish.

Any manager of a team needs to have a vision for where to take that team and what it
would be like to get there. As managers we need to grow in trusting our inner sense of
direction and in being courageous in acting on our revelations. It could be that for a while
we need to check our vision with those around us or even better those ahead of us but once
we ‘feel’ and ‘see’ that picture clearly before us we need then to act on it. If we can create
clear specific achievable goals for our teams that they can and do follow then we move on
from being Visionaries to Visionary Leaders.

In thinking for a moment about the characteristics and qualities of someone we would class
as a visionary leader – perhaps Steve Jobs or Nelson Mandela, we discover that there is an
element of the spiritual and emotional about this person as well as the core values that
have come together in creating an alluring charismatic quality that people have followed.

Without this enigmatic blend it would not have been possible to manifest their vision. A
visionary leader begins to embody their core values in a way that becomes very clear to
those around them, there is a sharp sense of commitment and integrity that energetically
radiate from those persons, a sense of urgency and vitality that touch on the spiritual. I
think that these visionary leaders start to “…be the change that they want to see in others”
to paraphrase the great Mahatma Gandhi.

Visionary leaders grasp the need to build up others and empower them to share the dream,
because of this they tend to treat others with care and respect realising that domination
is not the way but inspiration. There is a great sense of reward in seeing others grasp our
vision and make it their own. Team spirit, morale and ownership are highly prized stemming
from their desire to share and partner with those whom they work. This too in and of itself
reciprocates greater loyalty and trust from their team, if you know that the one leading you
cares you follow trustingly.

Visionary leaders are powered by transforming their surroundings and constantly striving
for change for the purpose of improvement.

Can a Software Development Manager be Scrum Master?

Recently I've been fulfilling the role of both Development Manager and Scrum Master in an Agile team and felt the need to blog about my experience - partly so that I wouldn't forget.

Ideally we know that your Dev Manager (Resource, Technical Quality, People Developer) manager should not be your Scum Master though at times due to resourcing needs and or other reasons the need may necessitate. In these circumstance it is important that the the right cultural tone is set, in our case I felt the need to ask one of the team to take on an additional role of  an 'Agile Conscience'. Where they could remind myself and the team of areas that we were slipping in - the team are of course encouraged to grow their own 'consciences' in this and other matters.

It was very subtle at times how there were certain dichotomies that the twin role posed for example issues could arise where it is not clear for the team as to who to go to for a quality concern that could impact the sprint. Greater care and emphasis needed to be made to ensure that the team was comfortable in bringing forth impediments to the Scrum Master/ Dev Manager that they may have been more reluctant to do as the Dev manager is filling this role as well. Team members also need to have a person they can rely on to understand their individual role, expertise and development - and how that fits into an agile team and the day to day of Sprints - the Dev Manager should be that person.

The Dev Manager fills a critical role – especially with a team that is new to Agile, in that they would lead the team through a change in the way a project is delivered - educating, informing and preaching the Agile approach. At times bridging the gap between management and Agile, perhaps there is an analysis gap or an education piece in making and empowering product owners etc...This is more possible as they would work very closely with Project and Product management on upcoming projects, they would be part of the discussions on the broader roadmap as well as ensuring the right skill sets are available when needed. Additionally, Dev managers should be pushing the team to follow development best practices around unit testing, pair programming, code reviews, continuous deployment etc... these are different goals in the short term to an Agile Scrum Master whose focus is the delivery and removal of empediments to the current sprint.

On a slighter note, though thinking about it it is quite important, the Scrum Master needs to be on the ball, minute by minute atuned to impediments or issues that may arise whereas the Development Manager should also give time to seeing things at a slightly higher level ie. where are there major inefficiencies in the team or the business where we can make a marked difference etc...

I hope this stimulates a discussion between us - please post your comments below.

Thanks

Conductor, Visionary and Cheerleader - Part 1: Conductor

Without doubt some of the key traits of software development management are that of:

• Conductor

• Visionary

• Cheerleader

...amongst many others, as development managers I know this sounds egotistical and self
promotionalist, but nevertheless I'll be bold and arrogant enough to continue what I believe
to be some of the key traits.

As a conductor - our role also depends on our ability to trust our sense of reading others
and seeing if they will fit in within the makeup of the team. If you find you've inherited a
team of prima donna's, that exhibit signs that they believe they alone know what the right
way to do things is and that all others are 'lesser beings' .... you may know the type...Well
then if and when you get an opportunity to hire into that team (only a question of time as
prima donna's will tend to jump ship often in their careers as opposed to transforming the
environment their in), you would need to hire someone that is both capable and yet not
arrogant. You'll know and sense where the sound of your team sounds too harsh or too soft,
too slow and listless or too energetic and chaotic, too inexperienced or too sure of
themselves that the basics are often neglected. As the conductor you must have the
courage to change and improve that unity. Courage also to resist the onslaught of reason
and pressure that requires you to hire quickly to fill the gap - if you don't you'll keep
performing at below par and waste money. Stay calm and stick to your convictions, its
better to hire the right person, someone that fits into the gaps of your team and
additionally someone you like and see yourself getting on with. Your ability to consistently
pick the right people and blend them into your existing team is one of your most important
traits.

A conductor also knows and trusts his musicians after all they are the ones producing the
melodies. Our job is to constantly develop and challenge them to achieve better - while
searching and discovering their own ideas about how their environment could be improved.
In showing that we really care, listening and making a real improvement to their
surroundings we enhance the ability we have to form effective teams. Some of the greatest
rewards of our role is seeing the improvement that people have undergone with our help
and how productive and united they have become.

Corporations that block social network tools.....

Can we not be trusted? Have you ever thought that when your corporation blocks access to social networking tools such as msn or facebook they are restricting your ability to problem solve quickly.

IT professionals are usually hired not only for their skills but additionally for their network of people. In restricting this access, then your inhibiting their ability to do what they've been hired by you to do!

Can discussions outside of work really be limited? how about emails from home? they are still subject to the discretion of the employee according to the contract he would've signed on joining the company. So why do we believe that by social network tools at work that we would be controlling what is said?

Then again if its about inhibiting productivity then are you sure you've hired the right people? Can they not be trusted to deliver on their word?

http://news.cnet.com/8301-30685_3-10377642-264.html