tag:blogger.com,1999:blog-52927932293439868842024-03-13T06:29:42.228-07:00Agile Techno Manager BlogTechnology Manager, Agile CTO, Scrum and other ramblings.Unknownnoreply@blogger.comBlogger5125tag:blogger.com,1999:blog-5292793229343986884.post-27703840329217928952011-10-27T16:45:00.000-07:002011-10-28T13:08:07.982-07:00Improving your software development process<div class="MsoNormal" style="line-height: normal;"><span style="font-size: small;">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.</span></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><span style="font-size: small;">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.</span></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><ul><li><span style="font-size: small;"><span style="font-family: Symbol;"><span style="-moz-font-feature-settings: normal; -moz-font-language-override: normal; font-family: "Times New Roman"; font-size-adjust: none; font-stretch: normal; font-style: normal; font-variant: normal; font-weight: normal; line-height: normal;"></span></span>Refactoring as you develop</span></li>
<li><span style="font-size: small;"><span style="font-family: Symbol;"></span>Drive for automated regression testing</span></li>
<li><span style="font-size: small;"><span style="font-family: Symbol;"></span>Automate your builds – Continuous Integration</span></li>
<li><span style="font-size: small;"><span style="font-family: Symbol;"></span>Industrialise your build process</span></li>
<li><span style="font-size: small;"><span style="font-family: Symbol;"></span>Agile Development Practices</span></li>
</ul><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><span style="font-size: small;">These of course are not goals in and of themselves as they deliver monetary and time efficiencies due to:</span></div><ul><li><span style="font-size: small;"><span style="font-family: Symbol;"><span style="-moz-font-feature-settings: normal; -moz-font-language-override: normal; font-family: "Times New Roman"; font-size-adjust: none; font-stretch: normal; font-style: normal; font-variant: normal; font-weight: normal; line-height: normal;"></span></span>Lower development costs</span></li>
<li><span style="font-size: small;"><span style="font-family: Symbol;"><span style="-moz-font-feature-settings: normal; -moz-font-language-override: normal; font-family: "Times New Roman"; font-size-adjust: none; font-stretch: normal; font-style: normal; font-variant: normal; font-weight: normal; line-height: normal;"></span></span>Lower maintenance costs</span></li>
<li><span style="font-size: small;"><span style="font-family: Symbol;"><span style="-moz-font-feature-settings: normal; -moz-font-language-override: normal; font-family: "Times New Roman"; font-size-adjust: none; font-stretch: normal; font-style: normal; font-variant: normal; font-weight: normal; line-height: normal;"></span></span>Faster time to market</span></li>
<li><span style="font-size: small;"><span style="font-family: Symbol;"><span style="-moz-font-feature-settings: normal; -moz-font-language-override: normal; font-family: "Times New Roman"; font-size-adjust: none; font-stretch: normal; font-style: normal; font-variant: normal; font-weight: normal; line-height: normal;"></span></span>Higher quality code</span></li>
<li><span style="font-size: small;"><span style="font-family: Symbol;"><span style="-moz-font-feature-settings: normal; -moz-font-language-override: normal; font-family: "Times New Roman"; font-size-adjust: none; font-stretch: normal; font-style: normal; font-variant: normal; font-weight: normal; line-height: normal;"></span></span>The deliverable is more adaptable to changes that may arise</span></li>
</ul><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><span style="font-size: small;"><b>Refactoring as you develop</b></span></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><span style="font-size: small;">“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. </span></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><span style="font-size: small;">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.</span></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><span style="font-size: small;">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.</span></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><span style="font-size: small;"><b>Drive for Automated Regression Testing</b></span></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><span style="font-size: small;">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.</span></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><span style="font-size: small;">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.</span></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><span style="font-size: small;">There are many tools and frameworks out there now to enable this to happen such as:</span></div><ul><li><span style="font-size: small;"><span style="font-family: Symbol;"></span><a href="http://selenium.openqa.org/">Selenium</a></span></li>
<li><span style="font-size: small;"><span style="font-family: Symbol;"></span><a href="http://webtest.canoo.com/webtest/manual/WebTestHome.html"><span class="blsp-spelling-error"><span style="text-decoration: none;">Canoo</span></span> <span class="blsp-spelling-error"><span style="text-decoration: none;">WebTest</span></span></a></span></li>
<li><span style="font-size: small;"><span style="font-family: Symbol;"></span><a href="http://clarkware.com/software/JUnitPerf.html"><span class="blsp-spelling-error"><span style="text-decoration: none;">JUnitPerf</span></span></a></span></li>
<li><span style="font-size: small;"><span style="font-family: Symbol;"></span><a href="http://jakarta.apache.org/jmeter/index.html"><span class="blsp-spelling-error"><span style="text-decoration: none;">JMeter</span></span></a></span></li>
<li><span style="font-size: small;"><span style="font-family: Symbol;"></span><a href="http://jbehave.org/documentation/web-integration/">JBehave</a></span></li>
<li><span style="font-size: small;"><span style="font-family: Symbol;"></span><a href="http://cukes.info/">Cucumber</a></span></li>
<li><span style="font-size: small;"><span style="font-family: Symbol;"></span><a href="http://concordion.org/">Concordion</a></span></li>
<li><span style="font-size: small;"><span style="font-family: Symbol;"></span><a href="http://fitnesse.org/">FitNesse</a></span></li>
<li><span style="font-size: small;"><span style="font-family: Symbol;"></span><a href="http://httpunit.sourceforge.net/"><span class="blsp-spelling-error"><span style="text-decoration: none;">HttpUnit</span></span></a></span></li>
</ul><div class="MsoNormal"><span style="font-size: small;">And many more…</span></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><span style="font-size: small;"><b>Automated Builds</b></span></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><span style="font-size: small;">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.</span></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><span style="font-size: small;">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!</span></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><span style="font-size: small;">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…</span></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><span style="font-size: small;">A good book for this is <a href="http://www.amazon.co.uk/Continuous-Integration-Improving-Software-Signature/dp/0321336380/ref=sr_1_1?s=books&ie=UTF8&qid=1319626640&sr=1-1">Continuous Integration – Steve Matyas and Andrew Glover</a></span></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><span style="font-size: small;"><b>Industrialise Build Process</b></span></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><span style="font-size: small;">I’ve separated this from the above Continuous Integreation as <a href="http://continuousdelivery.com/">Continuous Delivery</a> (<a href="http://www.amazon.co.uk/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912">Jez Humble & David Farley</a> 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. </span></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><span style="font-size: small;">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.</span></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><span style="font-size: small;">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.</span></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><span style="font-size: small;"><b>Agile Development Practices</b></span></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><span style="font-size: small;">A research <a href="http://www.forrester.com/rb/Research/agile_development_mainstream_adoption_has_changed_agility/q/id/56100/t/2">report published by Forrester in May 2010</a> 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.</span></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><span style="font-size: small;">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. </span></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><span style="font-size: small;">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. </span></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><span style="font-size: small;">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. </span></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><span style="font-size: small;">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.</span></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><span style="font-size: small;">For more on Agile check out the <a href="http://agilemanifesto.org/">Agile Manifesto</a> and the <a href="http://www.agilealliance.org/">Agile Alliance</a>.</span></div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5292793229343986884.post-82901236121316381492011-09-15T07:49:00.000-07:002011-09-15T08:49:59.552-07:00Conductor, Visionary and Cheerleader - Part 2: VisionaryWithout doubt some of the key traits of a software development management, CTO or CIO<br />
are that of:<br />
<br />
• Conductor<br />
<br />
<b>• Visionary</b><br />
<br />
• Cheerleader<br />
<br />
Proverbs 29:18 - Where there is no vision, the people perish.<br />
<br />
Any manager of a team needs to have a vision for where to take that team and what it<br />
would be like to get there. As managers we need to grow in trusting our inner sense of<br />
direction and in being courageous in acting on our revelations. It could be that for a while<br />
we need to check our vision with those around us or even better those ahead of us but once<br />
we ‘feel’ and ‘see’ that picture clearly before us we need then to act on it. If we can create<br />
clear specific achievable goals for our teams that they can and do follow then we move on<br />
from being Visionaries to Visionary Leaders.<br />
<br />
In thinking for a moment about the characteristics and qualities of someone we would class<br />
as a visionary leader – perhaps Steve Jobs or Nelson Mandela, we discover that there is an<br />
element of the spiritual and emotional about this person as well as the core values that<br />
have come together in creating an alluring charismatic quality that people have followed.<br />
<br />
Without this enigmatic blend it would not have been possible to manifest their vision. A<br />
visionary leader begins to embody their core values in a way that becomes very clear to<br />
those around them, there is a sharp sense of commitment and integrity that energetically<br />
radiate from those persons, a sense of urgency and vitality that touch on the spiritual. I<br />
think that these visionary leaders start to “…be the change that they want to see in others”<br />
to paraphrase the great Mahatma Gandhi.<br />
<br />
Visionary leaders grasp the need to build up others and empower them to share the dream,<br />
because of this they tend to treat others with care and respect realising that domination<br />
is not the way but inspiration. There is a great sense of reward in seeing others grasp our<br />
vision and make it their own. Team spirit, morale and ownership are highly prized stemming<br />
from their desire to share and partner with those whom they work. This too in and of itself<br />
reciprocates greater loyalty and trust from their team, if you know that the one leading you<br />
cares you follow trustingly.<br />
<br />
Visionary leaders are powered by transforming their surroundings and constantly striving<br />
for change for the purpose of improvement.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5292793229343986884.post-62346796795594108252011-05-16T09:29:00.000-07:002011-05-17T08:03:00.795-07:00Can 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.<br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
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...<br />
<br />
I hope this stimulates a discussion between us - please post your comments below. <br />
<br />
Thanks<br />
<br />
<span class="comment-body" data-li-comment-text=""> </span>Unknownnoreply@blogger.com13tag:blogger.com,1999:blog-5292793229343986884.post-73938457242676562142010-09-20T15:32:00.000-07:002011-09-15T07:46:50.064-07:00Conductor, Visionary and Cheerleader - Part 1: ConductorWithout doubt some of the key traits of software development management are that of:<br />
<br />
• Conductor<br />
<br />
• Visionary<br />
<br />
• Cheerleader<br />
<br />
...amongst many others, as development managers I know this sounds egotistical and self<br />
promotionalist, but nevertheless I'll be bold and arrogant enough to continue what I believe<br />
to be some of the key traits.<br />
<br />
As a conductor - our role also depends on our ability to trust our sense of reading others<br />
and seeing if they will fit in within the makeup of the team. If you find you've inherited a<br />
team of prima donna's, that exhibit signs that they believe they alone know what the right<br />
way to do things is and that all others are 'lesser beings' .... you may know the type...Well<br />
then if and when you get an opportunity to hire into that team (only a question of time as<br />
prima donna's will tend to jump ship often in their careers as opposed to transforming the<br />
environment their in), you would need to hire someone that is both capable and yet not<br />
arrogant. You'll know and sense where the sound of your team sounds too harsh or too soft,<br />
too slow and listless or too energetic and chaotic, too inexperienced or too sure of<br />
themselves that the basics are often neglected. As the conductor you must have the<br />
courage to change and improve that unity. Courage also to resist the onslaught of reason<br />
and pressure that requires you to hire quickly to fill the gap - if you don't you'll keep<br />
performing at below par and waste money. Stay calm and stick to your convictions, its<br />
better to hire the right person, someone that fits into the gaps of your team and<br />
additionally someone you like and see yourself getting on with. Your ability to consistently<br />
pick the right people and blend them into your existing team is one of your most important<br />
traits.<br />
<br />
A conductor also knows and trusts his musicians after all they are the ones producing the<br />
melodies. Our job is to constantly develop and challenge them to achieve better - while<br />
searching and discovering their own ideas about how their environment could be improved.<br />
In showing that we really care, listening and making a real improvement to their<br />
surroundings we enhance the ability we have to form effective teams. Some of the greatest<br />
rewards of our role is seeing the improvement that people have undergone with our help<br />
and how productive and united they have become.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5292793229343986884.post-24402534998578716962010-09-16T09:38:00.000-07:002011-05-17T08:04:40.733-07:00Corporations that block social network tools.....<span class="Apple-style-span" style="color: #333333; font-size: 13px;"><h3 class="post-title entry-title" style="color: #cc6600; font-size: 18px; font-weight: normal; line-height: 1.4em; margin: 0.25em 0px 0px; padding: 0px 0px 4px;"><span class="Apple-style-span" style="color: #333333; font-size: 13px; line-height: 20px;">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.</span></h3><div class="post-body entry-content" style="line-height: 1.6em; margin: 0px 0px 0.75em;"><div><br />
</div><div>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!</div><div><br />
</div><div>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?</div><div><br />
</div><div>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?</div><div><br />
</div><a href="http://news.cnet.com/8301-30685_3-10377642-264.html" style="color: #5588aa; text-decoration: none;">http://news.cnet.com/8301-30685_3-10377642-264.html</a></div></span>Unknownnoreply@blogger.com0