It’s All About Culture (Enterprise IT Beware)

15May12

This interesting post by PEG recently highlights an organisations culture as being in reality the only differentiating factor that they have. In his view assets, IP, cost competitiveness, brand and even people can be copied or acquired by your competition but it is your company culture that will lead to success/failure. I agree with his assertion on the importance of culture, and would add that whilst it has always been the case that culture is critical the rapidly changing new world is bringing with it new challenges to competitiveness resulting in culture becoming even more important for competitive advantage. I must clarify here that I see a huge gulf between the ‘official’ culture of an organisation that is documented and presented by senior management and the real culture that is living and breathing on the shop floor (and they rarely match).

This excellent highscalability.com post by Todd Hoff recently highlights the way that the rules framing IT (and business) are changing and how start-ups are becoming a beacon for investigating this new world. When we look at this new world the key elements are flexibility, adaptability and innovation. These traits thrive in start-ups where the ‘culture’ encourages them. Many of these new industry shakers lack the assets, brand and IP to use but excel in using their ‘culture’ to outmanoeuvre bigger rivals and drive innovation in their industry.

Some enterprises get this and are trying hard to foster a more innovative and customer focused culture. The emergence of agile development practices can help to focus the team on the true business value of features and aid flexibility in the use of resources. SAP has recently designed its new office environment to fully promote Agile development practices (see this post), and whilst this on its own can’t change corporate culture, it can remove some of the blockers to a more agile culture emerging. Of course there are many other enterprises that still rely on military inspired hierarchical structures and attempt to enforce a desired culture. This InfoQ article by Craig Smith summarizes recent articles covering how mainstream management are missing the benefits of an agile approach within their organisations. 

"…The management world remains generally in denial about the discoveries of Agile. You can scan the pages of Harvard Business Review and find scarcely even an oblique reference to the solution that Agile offers to one of the fundamental management problems of our times.”

The benefits of Agile practices are well documented and so if this fundamental approach is still not connecting with mainstream managers then how long will it be before they grasp the bigger paradigm shift that is occurring underneath them. This shift is being forged by start-ups and enabled via cloud computing.

Let’s look into what is happening in the start-up space; Todd Hoff’s post again highlights the use of small dedicated autonomous teams with the power (and responsibility) to make rapid changes to production systems. these teams being responsible for the entirety of their systems from design to build, test, deployment and even monitoring. How does this work? Well it can only work effectively via a shared culture of innovation, ownership and excellence. Facebook/Google staff have stated that their biggest motivator is the recognition of their good work by their peers (see here and here). This is ‘Motivation 3.0’ in action with the intrinsic rewards of the job at hand being the main motivation to succeed. Compare this with the traditional and still prevalent command and control approach used in a lot of enterprises with tightly controlled processes, working habits and resources. Splitting the responsibility for each stage of the development lifecycle between different teams (usually separated by reporting lines, internal funding requests, remote locations etc.) and then expecting a coherent solution to prevail is not going to work in this new world.

We are now starting to see the emergence of the cloud as a major force in driving the democratising of computing power and enabling the emergence of empowered teams. Todd’s post covers in detail how the cloud is making the once impossible possible and I recommend you take the time to read it. Only time will tell if the cloud’s impact on Enterprise IT will act as a catalyst to driving the emergence of more agile competitive corporate cultures in enterprises in the future.


Filed under: IT Observations, Methodology   |  Leave a Comment
Tags: , ,

New WordPress.com Source Code Live Writer Plugin Version

08May12

I’m pleased to announce the release of version 1.4.0 of my Windows Live Writer (WLW) Source Code Highlighter plugin for WordPress.com hosted blogs. For those not aware of this plugin it enables you to quickly insert a source code snippet into your hosted blog posts using the built in WordPress.com source code short codes. For more information and a run down of features checkout this page.

This is essentially a bug fixes release with some small new features: 

  1. Bug Fix: The previous version did not handle XML, HTML very well due to problem with HTML encoding. This has been resolved and so HTML, XML and also strings such as "List<T>" are now handled correctly.
  2. Bug Fix: Opening a previously published post from your blog that contained Source Code would often clear the post’s title and categories. This took a bit of head scratching but it turned out it seems to be a bug in WLW, which I have now circumvented. Old posts can now be retrieved with titles intact.
  3. Bug Fix: Some minor miscellaneous stability and refactoring changes. 
  4. New Feature: A requested feature was to have the ability to set a default programming language for the code snippets. After some prototyping I found it better to default the language to the one previously selected for the last inserted code snippet. This means that if you are, for example, normally inserting C# then you won’t need to change the language dropdown as it will default to the last one you inserted. Don’t forget you can customise the text file that accompanies the plugin to remove the languages you don’t use to make the dropdown smaller if you desire.
  5. New Feature: Since I released the previous version WordPress.com now supports these new language choices: ‘r’, ‘html’, and ‘clojure’. These have now been added to the language dropdown list for use via the plugin.

Still on the backlog list is an MSI installer, new version notifications and auto-update features. For now I hope you enjoy this new version, and thank you to all of you who have submitted feedback in the comments. The new version (1.4) is available here to download now.


Filed under: Live Writer, Tools & Tips   |  2 Comments
Tags: ,

Physical vs Virtual Kanban Boards

02Mar12

In previous posts I covered an introduction to Kanban and a review of a trial Kanban project. In this, my third in a series of Kanban posts, I’ll cover physical versus software Kanban boards.  For some this is an almost religious debate, and many would not question their decision for one other another. Whilst the answer for which is best will, of course, always be ‘it depends’, there are some fundamental differences that exist. I generally find that there is an expectation within IT that you virtualise everything, because well that’s what we do. Whilst this is often true I would add that a physical board should not be underestimated as out-dated and indeed should be considered equal for its significant merits in many areas.

Due to recent growth of Kanban there are now many software Kanban tools providing varying levels of functionality but all offering at the very least a virtual multi-user Kanban task-board. For a comprehensive list of these tools check out this AgileScout post. If you don’t like these tools then could always create your own in MS Access, Excel or even Word if you like. These might be enough to get you started for a Kanban proof of concept project but will of course lack the features built into specialist software such as MI, history tracking, cadence monitoring and reporting. Similarly physical boards can start out as being lines drawn on a whiteboard or string pinned out on a pin-board, then littered with post-it-notes. Either way the barrier to entry is low, although the Software As A Service (SaaS) model used by the many web based Kanban board providers will mean there will be a long term cost associated with utilizing a 3rd party tool. An alternative to a SaaS model would be to use on-premise Kanban software. For teams using Team Foundation Server you can easily build on your existing infrastructure by adding a Kanban viewer for your TFS work items. Telerik Work Item Manager for TFS has a taskboard view that can be customised and there are other Kanban based offerings that integrate with TFS (e.g. http://visualwip.codeplex.com). Microsoft can obviously see the power of this approach considering it’s now built into Team Foundation Server 11 which will have a web based taskboard view via the Web Access application, complete with workflow rules and drag & drop updates. Check out the screenshot below.

TFS11_candeleteThe first real difference between a physical and virtual board is the sheer presence that a physical board gives. On my project documented in part 2 of this Kanban series the move from a virtual software taskboard (albeit a very simple one) to a physical board made the whole method much more tangible and "real" to the team. It moved from being another software tracker to update to something different, something big and bold and in the room! You’re not going to miss a physical board on your way to the coffee machine forcing them to become a talking point in the office. Project stakeholders pay attention to it as it stands out when they’re in the team’s work area. The fact that we have hundreds of existing software based processes makes the introduction of a physical one slightly alien to the team and therefore grabs attention. Size is important here too, as teams can gather around the board for stand-ups ensuring a shared vision. Teams struggle to gather around a PC screen or print out. This ‘presence’ feature can be replicated for a virtual Kanban board by utilizing a large LCD screen and I would recommend that if you can do it. 

Of course the presence of a physical board is only good if your team is co-located. Remote teams are a challenge with Kanban as they are with any method or methodology and therefore a virtual board may be the only viable solution. In my recent project I utilised the on-site coordinator to act as a remote team proxy for the board which can work but is by no means ideal. A virtual tool allows everyone in the team to contribute regardless of their location.

A key aspect of the Kanban method is its simplicity and flexibility. Any board whether physical or virtual must be easily accessed, read, updated and changed. Continuous improvements to your processes are key and changing the board to reflect those changes should not offer any resistance. Complicated physical boards can be difficult to change as can some of the virtual tools. There’s no clear winner here but I would keep this in mind when reviewing Kanban software tools or when building a complex physical board.

The Kanban BoardVirtual boards provide the ability to easily produce MI and reporting information from your workflow, something just not possible with a physical board without manual work which could slow down the process. The ability for a team to track underlying trends and have up to date cadence figures is a huge benefit for an experienced Kanban team. I would suggest it may have less benefit for a team new to the process however as the Kanban method suggests that the board alone should be able to provide the data you need, but of course its not prescriptive and is open to adaption as a team sees fit.

One hurdle that some organisations struggle with is data security and privacy. Whether you class the data on your board as sensitive or not may influence your decision on the type of board to use. On one hand Virtual boards provide the ability to restrict access to verified users therefore maintain data security but on the other hand, many Kanban tools are externally hosted and therefore you are trusting your data to a third party. It’s not just security of course but also reliability of the vendor, e.g I’d hate to be mid project when my Kanban board disappears because the vendor has ceased trading. A physical board has its own challenges. Anyone in your office can see the board with no restriction on user roles. Without an automated change history it is also open to malicious changes from disgruntled colleagues. Backing up a virtual board is second nature but its harder to backup/restore a physical board, however taking regular photos is the best way I have found to date.

When I consider what would be my ideal board it would have to be easy, flexible, big and as integrated as possible with our existing systems. My ideal would be a virtual board with all the benefits that brings (especially remote teams) but it would have to have real presence in the office such as a large LCD on the wall constantly displaying the work in progress. In addition the screen would be a touch screen or alternatively put a terminal under display that was always logged in and used solely for the purpose of team members to update the board, thus removing the barrier for people to update the board. Of course the team could log on from their machines and update board but I see real benefit in walking up to the board to make changes, especially if required during a stand-up. This replicates the ability for you to physically move that post it note on the physical board. This setup should provide the majority of benefits of both approaches.

In summary, the choice is a personal one for your team and your circumstances, but for teams new to Kanban I wouldn’t underestimate the importance of having something bold that stands out and demands attention from the team and this is usually easier to implement with a physical board. Once the process is embedded and the board becomes a key part of the teams day then this would become less important and the power of virtual boards can be maximized.

For an excellent list of Kanban tools check out: http://agilescout.com/best-kanban-tools/.


Filed under: Methodology, Tools & Tips   |  2 Comments
Tags: ,

A Trial Kanban Project – What Worked. What Didn’t.

21Feb12

Recently I introduced Kanban to an inflight development project with the objective of trialling this technique with the team to raise productivity by overcoming various communication and process issues. In the first part of this 3 part series I presented an introduction to Kanban. This second part will cover the results obtained by introducing it to an in-flight project and part 3 will give some fuel to the "Physical versus Virtual Kanban boards" debate.

Project Background

This was a service release aiming to investigate and resolve a fixed set of production defects on a newly implemented enterprise scale system. The team consisted of 6 people onshore including Project Manager, Work Packet Manager, Technical Architect, System Analyst and 12 offshore developers (with limited experience of the system). This was a Waterfall project with the project plan based on the agreed prioritized defect list, a fixed resource and time-boxed approach. The number and complex nature of the defect investigations together with dependency management (with other teams) made the tracking of items within the project difficult and opaque which exposed the lack of a structured workflow within the team.

Approach Taken

Mid project I suggested the team adopt a Kanban approach and after explaining the concept to the team quickly got their buy-in. A quick virtual task-board was introduced (in Microsoft Excel initially) with columns defined based on the current informal process with added enforced quality assurance steps. Each work item (defect or change request) was added to the board and tracked, with updates applied daily by the team, as a very minimum, during a morning stand-up.

The task-board immediately brought a visual dimension to the project status making managing work in progress (WIP)easier and it also helped to bring focus to the daily stand-ups. After this initial success, to overcome the limitations of the virtual board and to get wider team involvement, the project moved to a physical board with very positive results.

The Kanban Board

The new board evolved from the previous version based on feedback and was simpler to use. Its physical nature and the fact that it was always on display for the team to consume made a huge difference and resulted in full team commitment to the approach. The physical board became the focal point for the daily stand-ups and for ad-hoc progress updates. The off-shore’s teams updates were applied regularly by the onshore coordinator. Team members used the Kanban queues to action work and move them to the next queue, monitoring/resolving blockages.

What worked well

Implementing Kanban was particularly easy compared to other methods and approaches. As the method logically represents a team to-do list it was easy to explain to people and therefore was not seen as a new complicated process which no doubt aided adoption with the team. It was immediately apparent that this method would compliment and not conflict with existing methodologies and processes. The fact that the board initially should mirror you current processes combined with the fact that it is a method not a methodology meant that it easily slotted in. Again this helped with team adoption and it received a very positive reception from the project team.

The team liked that Kanban immediately brought a visual dimension to project status. They could quickly see items in their queues and where the bottlenecks (if any) were. One quick glance at the board showed the current status of all items. This enabled the team to quickly provide progress updates and set realistic expectations with stakeholders outside the project team. Effort was saved by avoiding wasted deployments into test environments by being able to see at a glance what was going to be ready to deploy in the next build and then set early expectations with the QA team on whether they wanted to take the build or not.

As the flow of work was visualized and monitored it became easier to enforce the current process stages more explicitly. An item would have to pass through the "code review" stage before it could get to the "Ready to Deploy" stage – not only that but the process was completely transparent and clear to everyone involved. This aided communication too which facilitated the current process. As the process was transparent, and the team were able to use the stages as a common ‘vocabulary’, amendments to the process were easily discussed and small incremental process improvements were made, increasing the efficiency of the team. Kanban encourages this constant improvement and the flexibility of the method ensures that it is not a barrier to change.

From a project management perspective the board provided an excellent starting point for meeting updates and status tracking. With all WIP now visible the control of that work, and the resources involved became easier. It was this visibly that actually triggered  a useful resource allocation investigation resulting is resources being discovered to be under-utilised in one area and enabled reallocation.

On this project the move from a virtual software task-board (albeit a very simple one) to a physical board made a huge difference and it made the whole method very tangible and "real". Not just another piece of software to update but something different, something big and bold and in the room!

What didn’t work so well

With any new method a team has to find its feet and test the boundaries of what is productive and what isn’t. The rules to our process and our task board were not as clearly communicated to the whole team as at first thought resulting in some lack of full team ownership and involvement in the first few days. This was evidenced by some of the team acting as purely ‘read-only’ users initially until  they were encouraged to fully participate and engage with the method. Despite being a simple concept, without an explanation of the columns their meaning was open to a users interpretation. These were not problems with the Kanban method but merely communication problems that were quickly rectified.

It was discovered that the Kanban board could become misused. There was an urge to overcomplicate the board by adding more detail to the columns and the cards (such as expected delivery date and resource names). As our first board was virtual  we found that additional information could easily be added without much control.  This was stamped out early on after discussions within the team led to the information that was only required for reporting and tracking reasons being added or supplied from elsewhere as required. The board was simplified again and then a subsequent move over to a physical board helped eradicate this problem. 

We found that it was possible for the Kanban board to be used to just display the current status of work as opposed to being used as intended to drive work allocation. The board was being updated daily to reflect the days progress but the board was not driving the workflow and the team was not using the queues to allocate all their work. This meant that it was still adding value as an information radiator but not enabling its full potential. A similar problem was that some WIP items were not added to the board at all but managed separately. This was compounded if stand-ups were driven from an alternative list (defect tracker tool, meeting notes) instead of the Kanban board. All team members had to be reminded that all WIP had to be on the board no matter what the work was was, as it all had to be made visible. Luckily these issues were overcome by reminding people to use the board as the "one truth" and ensuring that all work was progressed via the board, which in a short time became embedded in the team practices.

An area where Kanban (and indeed most Agile methods) suffers is the ‘Remote Team’ scenario. The common assumption that all the teams are co-located is a common failing but one that has to be overcome using practical solutions where possible. Ideally teams need to be co-located for maximum efficiency but the use of telepresence, chat tools and conference calls can help. On this project we managed with an on-shore coordinator acting as a proxy to the offshore team and the Kanban board, combined with usual modern communication methods. Use of a good virtual Kanban board would potentially resolve some of these issues. To be clear Kanban did not introduce any additional impediments to remote teams than didn’t already exist within the team and its methodology.

Summary

This was just an informal trial of Kanban on a inflight project and so in the future I would like to extend the trial to other projects but with some adjustments. At project kick off I would not assume that the whole team had an understanding of the columns and the workflow process, and would ensure full buy-in. More monitoring of ‘cycle time’ would be advised to gain more insight into the current process. I would also like to trial some of the professional virtual task-board software on the market, together with possible integration with Team Foundation Server Work Items. 

In summary the Kanban method worked very well on this project and with its simple/flexible approach I’m sure that it can be useful on a huge variety of projects. Critically the feedback from this project team was extremely positive, so much so that team members actually went on to implement Kanban on their other projects afterwards. It was seen by the team (and stakeholders) as a successful work tracking and communication technique, whilst also providing the opportunity to continuously improve. I highly recommend considering trialling Kanban on your future projects, and if you can’t manage to go that far then at least start to think how you can visualize your work in progress.


Filed under: Methodology   |  2 Comments
Tags: , , ,

An Introduction to Kanban

13Feb12

Recently I introduced Kanban to an inflight development project with the objective of trialling this technique with a hope to raising productivity by overcoming various communication and process issues. In this three part series I’ll cover my real world experiences and the results felt by the project/team. This first part offers an introduction to Kanban, part 2 will cover the results obtained by introducing it to an in-flight project and part 3 will give some fuel to the "Physical versus Virtual Kanban boards" debate.

Kanban has been used in manufacturing for many years and is rooted in the Kaizen (continuous improvement) philosophy documented in the Toyota Production System. It has been used in the manufacturing industry for many years. It’s focus in the field of Software Development came with the book by David Anderson. Kanban in the Software Development sense is …

“… a method for developing products with an emphasis on just-in-time delivery while not overloading the developers. It emphasizes that developers pull work from a queue, and the process, from definition of a task to its delivery to the customer, is displayed for participants to see”. – Wikipedia

Kanban is not a methodology but an enabler to the goal of Continuous Improvement: The Kanban Method encourages small continuous, incremental and evolutionary workflow changes that stick over time. When teams have a shared understanding about the flow of work they are more likely to be able to build a shared comprehension of a problem and then suggest improvements that can be agreed by team consensus.

Visualization of work has become very popular in agile development practices. XP, for example, has “informative workspaces” that display project progress at a glance and the use of “Information Radiators” is gaining ground (i.e. graphs or charts on the wall showing graphically the work in progress within the team or project. This work is too often hidden and so by publicizing the flow of work we can start to understand the real processes in place and how work flows to completion. Once you have that understanding (and can easily share it)  you can start to make improvements.

imageKanban development revolves around a visual task-board used for managing work in progress: A progress board but with rules! The columns on the board represent the different states or steps in the workflow and the cards/post-it-notes represent a unit of work (the feature/user story/task etc.). We then move the cards along the board through each process stage (i.e. column) to completion. A look at the board at any one time shows which items of work are currently within each stage of the process.    

In order to limit the concurrent work in progress within the team we add rules to the Kanban board and set WIP limits on each column, e.g. only 6 items can be in QA at any one time as that is the max capacity of that team. No more work can be assigned to the QA queue whilst it is full. This limit enforces that new work is only “pulled” into the QA queue when there is available capacity. This immediately reveals the bottlenecks in your process so that they may be addressed. Once we spot a bottleneck we stop adding more work to the bottlenecked queue and collaborate within the team to eliminate the blockage (e.g. move resources off build tasks and onto QA tasks). It’s important to note here that we are not artificially introducing a limit here, as we have created the board initially based on the current workflow and therefore the limit exists in reality (e.g. only a single team member can perform part of the process) but it may not have been currently visible to the team.

imageDon’t underestimate the power of a visual progress board! It’s useful for all project stakeholders to see the latest project status, including senior managers. It might even replace that dreaded status report. The flow of work through each state in the workflow can be monitored, measured and reported (if desired). By actively managing the flow the continuous, incremental and evolutionary changes to the system can be evaluated to have positive or negative effects on the system. Ultimately we want to figure out how to keep development and throughput running smoothly by tracking down bottlenecks and then adjusting our workflow or our resources to eliminate them. We may be able to relieve repeated bottlenecks by changing the number and types of people in each role and cross training our team. One thing that can be monitored is the ‘cadence’ or rhythm of the pace of change. How long does it take for an item to be completed once its added to the board (i.e. its travel time from left to right)? This cycle time can be calculated as: 

Cycle Time    =     Number of Things in Process  / Average Completion Rate

A critical benefit of Kanban is that it is very simple to implement, use and improve. Knocking up a task board on your current process is straight forward and team members soon pick up the approach which really aids team engagement. In addition as it is not a methodology in its self it can be used within your existing methodology and actually provides a more gradual evolutionary path from Waterfall to Agile. It is also less dependent on cross functional teams than Scrum. Using Kanban to manage tasks within the Design, Build and Test phases of a Waterfall project can prove very successful regardless of the wider methodologies in use. In addition, the ability for it to handle irregular, ad-hoc work makes it also especially good for managing defect resolutions within a build team or for a Operations/Service team handling incidents.

A 2010 case study with the BBC Worldwide team using Lean methods including Kanban recorded a 37% increase in lead time improvement, a 47% increase in delivery consistency and a 24% drop in defects reported. This was not all due to Kanban, but Kanban appears to have been a key ingredient together with smaller batch sizes, stand-ups  and an empowered team.

I think that Kanban is a very powerful approach that can fit within your existing methodology well (including Waterfall) to drive benefit and importantly Continuous Improvement. For more information on Kanban check out these links:

http://www.kanban101.com/
http://en.wikipedia.org/wiki/Kanban_(development) 
http://www.agileproductdesign.com/blog/2009/kanban_over_simplified.html
http://www.crisp.se/kanban
http://www.infoq.com/articles/agile-kanban-boards
http://www.infoq.com/articles/hiranabe-lean-agile-kanban
http://www.kanbanblog.com
http://en.wikipedia.org/wiki/Lean_IT


Filed under: IT Observations, Methodology, Tools & Tips   |  4 Comments
Tags: , , ,

The Enterprise & Open Web Developer Divide

06Feb12

In this interesting Forrester post about embracing the open web Jeffrey Hammond highlights the presence of two different developer communities. In his words:

"…there are two different developer communities out there that I deal with. In the past, I’ve referred to these groups as the "inside the firewall crowd" and the "outside the firewall crowd." The inquiries I have with the first group are fairly conventional — they segment as .NET or Java development shops, they use app servers and RDBMSes, and they worry about security and governance. Inquiries with the second group are very different — these developers are multilingual, hold very few alliances to vendors, tend to be younger, and embrace open source and open communities as a way to get almost everything done. The first group thinks web services are done with SOAP; the second does them with REST and JSON. The first group thinks MVC, the second thinks "pipes and filters" and eventing."

Following the tech industry it is clear to me that this division is tangible and in fact I would suggest the gap is currently increasing. I recently started to revisit my open web development skills after it occurred to me how large this divide was beginning to get and how important these skills will be key in the future. Whilst the Enterprise developer often traditionally focuses deeply on a handful of technologies (too often from one Vendor) the Open Web developer is constantly learning new languages and choosing between best of breed open source frameworks to get the job done. The new Open Web developer has evolved from a different age and with different perspectives and in many ways leaving behind the rules/constraints of the Enterprise developer building typical Line Of Business (LOB) applications. I’m not suggesting that Enterprise developers don’t understand these technologies already, I assume many do, but they’re unlikely to be living and breathing them. This is not just about web development technologies and techniques, but more about mind-sets, architectural styles and patterns. Perhaps it can be viewed historically as similar to the evolution from mainframes to distributed computing, and this is just the next evolution. This movement compliments the emergence of cloud computing and one can assume that the social, dynamic LOB applications of tomorrow will rely heavily on the skills and technologies of the Open Web community. To quote Jeffrey again:

"In the next few years, their world is headed straight to an IT shop near you."

The proliferation of devices, cloud computing and a new breed of ‘surfing since birth’ young blood entering the industry combined with the shift towards this new world from big players like Microsoft (e.g. using JavaScript to build Windows 8 apps) mean that Enterprise IT will have to converge with the Open Web approach in order to meet future consumer needs. Only the integration of these worlds will enable Enterprises to integrate their existing application landscapes with the new web based consumption model.

John R. Rymer’s Forrester post on the subject provides his view on the differences between these communities and his accompanying post details the technologies you need to focus on now (HTML5, CSS3, JavaScript, REST). Whilst it can be tricky to follow this sort of fast moving decentralized movement, the good news is that now is a great time to get into these technologies with the growth of the umbrella HTML5 movement raising awareness within the industry and bringing some standards to advanced web design. Keep an eye on what the big web frameworks are offering, and track the innovations at companies like Google and Twitter. I recommend you read these Forrester articles and think about how this affects your architecture, IT organization and career.

For some quality content on these technologies check out these links:  ‘Mozilla Developer Network’, ‘Move The Web Forward’ and ‘HTML5 Rocks’.


Filed under: Architecture, Cloud Computing, ASP.Net, Learning, IT Observations   |  Leave a Comment
Tags: , , ,

Enterprise IT Project Insanity

16Jan12

A study published in the Harvard Business Review  has again shown that many IT projects continue to come in late and over budget. In addition it shows that there is a higher than expected number of large scale failures. These failures are massively over budget (200% in this study) and over deadline (70% overruns) and it cites examples where this has even contributed to the collapse of the company or at best reduced its profit forecasts leaving it at the mercy of the City. It’s interesting reading with the study showing that in total 27% of the 1471 projects overran in some way.

Now you could argue that these are mostly major IT transformation projects and hence the risks associated with them are bound to be significant (although this highlights another fact in that if the project was seen as transformational then perhaps there is an absence of a culture of continuous improvement at those organisations). Regardless though this is still damming evidence of the ability for this industry to implement IT projects. A comparison with other industries has been made on numerous occasions and IT tends to come out worst for achieving project success (although it’s not alone with many large defence sector projects for example suffering too).  There are many reasons for IT projects to fail and I’m not going to cover them all here but instead ask the question why are we still repeating the same mistakes in many organisations. It has been 36 years since Frederick P Brooks wrote the seminal book "The Mythical Man Month" yet many of its key themes within his essays remain problems today. Walk around many traditional enterprise IT departments today and you need to avoid the Tar Pit on your way to joining the  Death March on the "Tower Of Babel" project. For those of you not familiar with the book, the Wikipedia article on it summarizes it well. Some concepts will seem obvious and basic pitfalls but don’t forget this was written in a different age. The key points made in the book being the importance of progress tracking, tooling, communication and the iconic Mythical Man Month (whereby assigning more programmers to a project running behind schedule will make it even later, because of the time required for the new programmers to learn about the project, as well as the increased communication overhead).

So what has changed in 36 years?  In some ways a lot has changed: The emergence of Lean/Agile practices and Motivation 3.0? (check out Daniel Pink’s work on intrinsic motivation) have dragged the thought leaders in the industry in the right direction (usually forced via a groundswell movement) but crucially the impact of these innovations vary by company and corporate cultures. It seems in many traditional enterprises little has changed. We continue to march on for projects destined to fail with old world approaches, planning in the ‘mythical man months’ based on ‘lies’ (sorry ‘estimates’). We still see people being thrown at a problem to resolve it despite this being a known anti-pattern.  Many of the new approaches aimed at addressing these problems (e.g. lean/agile etc.) thrive in the smarter/learner enterprises and technology companies but have have struggled to get traction in the traditional red brick enterprises despite the impressive results of agile/iterative approaches. Even those enterprises that have adopted them have struggled to instil the philosophy behind Agile and instead just dogmatically implement an specific Agile methodology. The shift is happening but what’s stopping faster evolution in these enterprises?

Many of the issues could be classed as cultural, organizational or management issues and so can we can blame the senior management? Well that is way too simplistic and all stakeholders in an IT project have a part of play in its success or failure.  Perhaps more likely is that the management tools, processes, procedures and attitudes that manage a modern enterprise don’t naturally fit to managing software development. In some ways this is not surprising as these enterprises are busy managing their core competencies (finance, manufacturing, construction, logistics etc.) with software development being done internally without the focus it perhaps needs. Take the world of banking as an example. A bank might spend millions on its IT and perhaps even consider some of it’s IT systems to be a competitive advantage, however it is a bank, not a software house and any activity within the organisation must fit the internal processes whether that fit is a natural one or not. In my post about the "Future of the IT Department" I covered how these IT departments have become large and unwieldy beasts. Fitting software development into a non-IT enterprise can be difficult and rigid. How many times have you had to bend software development reporting to fit into a model for which it doesn’t naturally fit? We have all had to dumb down technical analysis of issues/risks/progress into bite size chunks of simplistic bullet points that fit neatly into a PowerPoint slide but convey little in the way of accuracy. No doubt you get dragged into needless conference calls as a result of someone misunderstanding the technical situation. That’s not to say that those we report to are not intelligent (often far from it) but that they often lack the required skills to manage technical details. So what about the IT experts who progress up to management, they understand the problem right? Well yes they did, but it doesn’t take long to adjust to the culture of the organisation as it is a necessity for them to do so. They cannot do their job without following the processes that run the rest of the business and they need information/milestones/gateways to track progress. The industry is getting wise to this down at the development team level however as new tools emerge through the agile space that track the progress and velocity of a development team in easy to consume visual ways (e.g TFS v.next). Whilst these are not intended to be consumed at exec level I expect that more accurate reporting at the local level will result in better reporting flowing up the organisational structure. The pace of change in the industry is to blame also here for the managers of today were the IT guys of yesterday when different architecture landscapes were around and Mainframes were king.Where there is an inability for management and IT professionals to communicate and share a culture the gulf is  filled with consultants and IT sales reps which can compound the problem. The use of Offshoring and outsourcing can also make the problem worse as the barriers to communication are now formal 3rd party engagements. We need to find a common ground to fill this cultural divide in an effort to help speed up the evolution of change.

It’s not unusual for these large enterprises to use Waterfall methodologies and tightly control the IT department resources so that IT can be managed neatly within the organisations financial and resource planning models. This will only get more engrained over the next few years as the economic climate dictates tighter financial controls and risk monitoring. This of course does little to aid the progress of IT evolution unless risks are taken to counteract the cost squeeze with more agility. The study mentioned above also highlighted that those projects that do succeed are often using Agile approaches and focusing on customer value, which makes sense. IT projects are one-off bespoke creations and yet are managed as though they were identical widgets produced on a production line. Enterprises are organised into a post war hierarchical command and control structure that is structured to actually avoid the communication between teams yet we still apply that model to the IT organisation in many enterprises. If we look at the likes of Google and Facebook, their developers are given more autonomy (and responsibility) for the software they build and its implementation, test, adoption and its evolution. They are encouraged to deploy often and innovate with trust placed upon them based on the fact that Software development is a skill and one developer is not as replaceable with another as is often assumed (explained brilliantly in John Miano’s post here on The Myth of the Interchangeable Programmer). In comparison the enterprise developer more often than not sits in India creating code based on detailed specifications (based on wrong assumptions at a point in time) separated by offshore coordinators, managers, on-shore coordinator’s, and a few thousand miles of undersea cable from the business they serve – stifling their ability to add value. When quality of output into test drops the next project is assigned more testing time and resource to catch defects, but at the expense of the design/development time. this leads to rushed design/build and again lower quality, so again more testing is required. And then in response there is a whole bureaucratic process of change management policies to rightly protect service. I’m not suggesting that change management processes and IT policies are not important (or indeed vital) but there is a balance between innovation and risk aversion that must be reached for the benefit of the company and for enterprise IT to evolve.

As the downturn in the economy bites cost controls will be tightened and IT departments trimmed, more often than not replaced by off shore labour, but this is an opportunity to rethink the approach and evolve the IT organisation into something leaner backed by more autonomy and lean processes. Agile/Iterative approaches have been proven to reduce costs and improve quality in comparison to traditional methods. Enterprises need to fully embrace Agile and encourage innovation within smaller business aligned teams of IT, relax some of the processes and abandon the often rigid enforcement of "Waterfall For All" and instead enable teams to choose the methodology that best fits.

IT within enterprises is evolving slowly but perhaps a revolution is required to speed things up, are you ready to revolt?


Filed under: IT Observations   |  3 Comments
Tags: , ,

Embedding Pro-Active Tasks In Your Dev Team

16Jan12

We have made huge advances over recent years in the tools available to the development team, including the more proactive and investigative tools (profiling tools, code analysis, performance analysis, debugging etc). However demanding project timelines mean that we have increasingly less time to investigate, trial and use these tools. Compounding the problem is that unfortunately the first thing to get abandoned on a tight project are the proactive development tasks that lead to a better quality project but that don’t necessarily help get ‘something’ out the door. Obviously we need to try to get these approaches embedded into the development lifecycle despite their upfront costs. At first glance this seems a difficult challenge but then consider automated unit testing. This proactive task of developing tests alongside your code was a hard pill for many to swallow initially (and still is in some organisations) but as an industry we embedded the believe that the effort was worthwhile and the result was better quality, more tested and rigorous code. The same approach needs to be considered for other proactive tasks. Here’s a simple guide for getting something proactive adopted by your dev team:

  1. Firstly the task need to be qualified: what is the task, what benefit does it provide, when would it be best used and what are the costs associated with not doing it?
  2. Evangelize to the wider team. Hold demo’s of the approach to build awareness. Try to focus on one approach first and build a buzz around it so that it fixes in people’s daily psyche so it seems odd not to take the approach. Don’t forget to include the wider development stakeholders (Business Analysts, Architects, Project Managers) too as they may be impacted for better or worse. Use the concept of ‘Technical Debt‘ to help justify the long term impact of decisions affecting system quality.
  3. Automate, automate, automate! How can you make it easier and quicker to get the initiative embedded in your development process? Can it be incorporated into your automated Continuous Integration solution for example?
  4. The effort involved with the approach will need to be quantified so that they can be factored into development task estimates for project planning early enough to enable projects to be planned with these initiatives included. it is much harder for to find the time (and project manager commitment) for unplanned tasks. 
  5. Pilot the approach on small projects to be able to refine the approach and prove the benefits.
  6. Include the approach in your ‘done lists’.
  7. Vocalise and Visualise. Document the results/benefits of the approach and shout loudly when it avoids a production incident or missed deadline.

I would say that the most important step is the second one – Evangelising to your colleagues. it’s hard to stop a groundswell of enthusiasm for a new approach and you’ll progress much faster with peer support.


Filed under: Tools & Tips, IT Observations   |  Leave a Comment
Tags: , ,

No VS with Notepad++ and Programmers Notepad

05Dec11

Sometimes, despite Visual Studio being an excellent IDE, you want to go the No VS route and hack your code in notepad. Perhaps you just want to make a quick change and its not worth firing up the full VS experience. Maybe you are only checking the code as a background time-filler in between other tasks you don’t want VS eating up your workstations resources all day. Perhaps most likely you’ll need to edit your code on a PC without VS (e.g. Netbook). A while ago I came across this excellent post by SecretGeek where he’s used a batch  script to add compilation to the excellent Notepad++. I recommend taking 5 minutes to follow his instructions and get this working as it makes Notepad++ even more useful. Don’t forget you will need to change the .Net framework path in the batch file if you’re coding apps older than .Net 4.0.

I’ve also copied the batch file and then modified it to work for solution files too, so I can compile the whole solution if required instead of just the project file. I’ve then added a second entry in the Notepad++ file (as per SecretGeek’s instructions) and a second shortcut key for this batch file. The only change required is to amend the “*.*proj” to “*.*sln”.  This change assumes that the project and solution files are NOT in the same folder though as this confuses the .Net compiler.

As good as Notepad++ is as a notepad tool, if you need something a little more like a mini IDE then I recommend “Programmers Notepad”. Not only is it an excellent lightweight Notepad like tool but it also supports “projects” and tools. By far the best feature though is that it parses the output from the compiler and highlights the results. Also clicking on the error will take you straight to the offending line of code (see screenshots below).

CompileNetProject_ErrorAndGoToErrLineCompileNetProject_action

It is easy to integrate SecretGeek’s above batch files into Programmers Notepad.  Go to Tools > Add Tool, and set it up like this:

CompileNetProjectCompileNetSln

Now we’re cooking! So what’s left? Well what about being able to run your Unit Tests from this mini IDE? Let’s assume Visual Studio is installed on the machine in question (which negates the point of the exercise perhaps, but not always as sometimes you have it installed but just don’t want to run the full blown VS IDE) so we can run MSTest via a batch file. For this batch file to work though we have to make a few more assumptions:

1 You will always run the tests whilst the unit test project code is the open active document in Programmers Notepad.
2 The test assembly name is the same name as the test project file.

Using these assumptions we can code the RunTests.bat batch file to find the active document’s VS project file (*.*proj) and use its name to find the output assembly name in the bin\debug folder. Once we have the test assembly we can throw it at MSTest for it to run the tests. Assigning this new batch file to a Tool menu item in Programmers Notepad (as we did with the other batch files above) we can run the tests within Programmers Notepad and the test results will be output into the output window.

RunTests

The code for the RunTests.bat batch files is:

@ECHO OFF

Set MSTestPath="C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\MStest.exe"

:findproj

Set current=%cd%

If not exist *.*proj goto tryFindProjAgain
REM get project file name
FOR %%f IN (*.*proj) DO Set dllname=%%f
REM Convert proj file name to test assembly name
set dllname=%dllname:csproj=dll%
Set fullpath=%cd%\bin\Debug\%dllname%

%MSTestPath% /testcontainer:%fullpath% /detail:errormessage

goto end

:tryFindProjAgain

ECHO No project file found in:
ECHO %cd%

cd ..

REM detect if we are at the root level
if "%current%"=="%cd%" goto end

goto findproj

:end

Filed under: .Net, Tools & Tips   |  Leave a Comment
Tags: , ,

Using SlickRun For Fast PowerShell Commands

15Nov11

I’m a big fan of SlickRun and if you’ve not used it I recommend you download it and give it a try. I find it an invaluable tool not only for launching apps but also web sites, collections of applications and directories etc. It’s the simplicity of SlickRun that makes it so powerful. Sure there are newer, and certainly prettier launchers out there but SlickRun is still the best in my opinion. Whilst it’s usefulness is slightly diminished by the Windows 7 start menu search it still has its place for providing shortcuts of any name you like, and for running multiple apps off one command. Anyone reading this blog will no doubt have spotted that I also am a fan of Windows PowerShell, so I’ve now combined the two. The objective being to run simple PowerShell commands within SlickRun and have the results appear quickly in a console (with no coding).

PowerShell can be run with start up parameters (see the documentation here). The one’s we need to use are:
-NoExit to not exit the console window after running the command (so you can see the results)
-command to executes the specified command as though they were typed at the Windows PowerShell command prompt.

The SlickRun setup for the MagicWord (I’ve used ‘POSH’ in this example) is:
MagicWord: POSH
Filename: powershell
Parameters: powershell -NoExit -command "$I$"

The filename can be just "powershell" or if you feel better you can put in the full path to the PowerShell exe. Passing the command text as "$I$" just passed in what you typed in SlickRun after the magic word.

We can then just use the POSH keyword followed by the command we wish to run. For example this keyed into SlickRun…

Posh1

launches the PowerShell console and the results…

Posh2

Of course this approach can be used from other application launchers, directly from the command line or the Start-Run dialog but then of course you will have more to type as you will need to key the start-up parameters each time.


Filed under: PowerShell, Tools & Tips   |  Leave a Comment
Tags: , ,
« Older posts
Follow

Get every new post delivered to your Inbox.