Rewiring Brains

Personal development is often viewed as ‘fluffy’, with little relationship to the bottom-line, not something a CIO would hang a vision and strategy on. This blog series demonstrates that the reverse is true. If we are to make the most of the brains in our companies, we need to start re-wiring these machines, understand more about how our brains work, and use tools that harness our strengths and protect us against our weaknesses.

The Wiring

From the moment we are born we are being wired-up. As we open our eyes, feel the cold, scream in protest and are coddled in our mother’s arms we are creating synaptic connections. As we learn a new skill we create new neural pathways, these pathways with repeated experience, become a track… a street… a highway and a super-highway. These neural super-highways are the synaptic patterns of our experience and personality. They define our values, beliefs, decisions, memories and meta-programs that ultimately define who we are and how we see and interpret the world.

In any one second our senses allow us to receive an estimated 2 million bits of data per second. We have the ability to be consciously aware of about 7+/- 2 streams of data at any one time, roughly equating to 134 bits per second.

From this constraint we have evolved to identify patterns within the information overload – to recognise data points in our sensory perception, interpret that data at the conscious and sub-conscious level and respond.

That is to say, that at a biological level, our brains have evolved to take in very small amounts of data, identify patterns and make decisions. This leads to a natural ‘need’, ‘desire’ or ‘expectation’ to solve problems rapidly with a single solution.

The Impact

Our ability to filter data, recognise patterns and act has a large impact on the way we work, it affects everything we do, how we interpret the environment, interact with each other and make decisions. There are both positive and negative effects.

The positive effect is the ability to understand a context rapidly, identify potential solutions, and select a solution and act, essential capabilities in urgent, tactical, operational environments where speed is essential. The negative side of this is the ability to filter out data that doesn’t immediately make sense, ignore data that doesn’t ‘fit’ previous experience, or not spend enough time understanding the problem before moving to a solution. In other words, we are so well wired to make quick decisions on limited data that on the occasions when we have time and data to make a more in-depth decision, we often lack the ability to change and adapt our approach.

This problem is more pronounced when working with complex processes such as software development, as our ‘need’ to provide solutions, regularly inhibits our ability to fully understand and resolve the root-cause of problems.

Re-wiring

There have been a number of techniques designed to structure our problem solving abilities. They have been developed in many industry verticals from health care to automobile manufacturing, from new town design to software development, emphasising the ubiquitous need for strong problem-solving skills.

Two particularly useful tools that have cross-industry adoption are Design Patterns & A3 Problem solving. Design Patterns originally developed by the architect Christopher Alexander provided a framework for codifying the context of a problem and applying solutions.

“The elements of this language are entities called patterns. Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.”

Design patterns have been adopted in Software development and were popularised by the Gang of Four in their 1994 book “Design Patterns: Elements of Reusable Object-Oriented Software”. More recently design patterns have been used in organisational design (pioneered by the work of Coplien), to provide companies with tried and tested patterns for team and organisational design to solve problems in organisational performance.

A3 problem solving is a tactic within the Lean Thinking methodology, to help our brains spend enough time in the problem domain to understand the problem background, the current problem, the intended outcome, and the root cause before trialling multiple solutions as experiments and recording the outcome. Again, Lean Thinking has been adopted across multiple industry verticals particularly in the US.

In today’s corporate world, with the CIO in a more strategic position, such a tactic could prove invaluable. When CIOs are being asked to innovate while at the same time provide income generating solutions, the ability to enable your teams to address the root cause of a problem and focus on measurable outcomes to achieve business goals, could prove vital to achieving competitive advantage.

By understanding more about ourselves and how we perceive, interpret, and interact with each other and the world, we will create more effective teams and organisations.

Personal development and organisational structures are often viewed as the ‘fluffy’ stuff, with little relationship to bottom-line. This Blog series will attempt to demonstrate that the reverse is true. In this third blog, we’ll examine the overall effect of working in a rapidly innovating industry with a long-term talent shortage.

Perpetuating Dross? An Industry Dilemma

The software industry is young. It’s only been around for about 60 years… We’re still finding our feet and demand for our product is increasing exponentially. Banking and Retail have had millennia to refine their practices; we’re still learning ours… When we then add to this learning curve the scarcity of resources, it’s easy to see why in 1994 the Standish report were stating only 16% of software projects were successful.

Projects have been so unsuccessful that C-level executives ripped the software development capabilities out of their companies and off-shored it to countries like India, I once heard that “If I’m going to have projects that fail, I’d rather fail cheaply.”

However, more damaging to the software industry is not its embryonic stage, nor its learning curve, nor even the scarcity of resource, but the acceptance of poor product as the norm – the perpetuation of dross.

Customers of software have become accustomed to and accept defects as part of the product offering. Not only that, but also they expect and are prepared to upgrade products themselves, on a regular basis, and pay for the privilege of doing so in support and maintenance contracts or annual licensing.

In what other product development vertical would it be acceptable to have so many defects?

One of the effects of poor software implementations has been the creation and growth of an entirely new industry the Customer Services Call Centre. Companies understand that their technologies and processes are not aligned and faulty, so they establish huge customer service operations to answer customer queries and complaints and resolve the errors.

A further effect of accepting poor quality software production is the institutionalisation of waste within corporations. Executives attempt to control the situation by implementing more and more processes, bureaucracy and safety nets, as well as customer services, service management teams, and DevOps teams. This creates more cost, complexity and opportunities for error.

If each company made the time and resources available to solve root cause issues, then companies would learn to create and deliver the most value from the customer’s perspective, while consuming the fewest resources, by fully utilizing the knowledge, skills and thinking of those who perform the work

So poor product development within software has become the norm, we are perpetuating dross.

We create poor product, customers accept poor product, and therefore we are justified in creating more, poor product. We don’t evolve, we don’t improve our profession, we accept mediocrity in the name of profit and the cycle continues.

If you look at any other mature profession there are some key, visible elements… Doctors, civil engineers, solicitors, and bankers have set qualifications, apprenticeships, certifications, accreditations, regulators and associations. This represents a huge investment in the capabilities of the profession – how does the software industry compare?

Software development is in its infancy, we are all still learning, and we should be creating learning organisations. We should not accept poor quality product, and we are damaging the reputation of our profession by continuing to accept this course.

We’ve been working with a small, ambitious, energetic financial services technology company. They’re a ‘green-field’ agile site, with executive sponsorship for agile adoption and a large portfolio of work to deliver.

Having assessed their portfolio, capacity and skill-sets they’re looking to increase their team size by recruiting a Scrum Master, a .Net Developer and an Agile Tester.

If you’re interested in working in a small company, in south-west London, actively adopting agile practices, where the results of your efforts are clearly visible, please contact recruitment.uk@ripple-rock.com

http://www.ripple-rock.com/about-ripplerock/careers-uk.aspx

http://www.ripple-rock.com/about-ripplerock/careers-uk/agile-tester.aspx

http://www.ripple-rock.com/about-ripplerock/careers-uk/agile-developer.aspx

http://www.ripple-rock.com/about-ripplerock/careers-uk/scrummaster.aspx

Original Post: http://businessvalueexchange.com/brains-are-machines-series-blog-2-innovation-automation-investment/

Personal development is often viewed as ‘fluffy’, with little relationship to the bottom-line, not something a CIO would hang a vision and strategy on. This Blog series: Brains Are Machines, attempts to demonstrate that the reverse is true. In this second blog, we highlight that despite our rapid innovation and adoption of automation within software development, the need for higher levels of investment in developing people remains.

Innovation

Technology innovation is rapid, the speed of innovation is accelerating and technology is ubiquitous. So whichever way you look at it, you either need to excel at creating & distributing software or you need to excel at assessing, purchasing and integrating software into your existing architectures, processes, people and culture. And this trend is only going to increase.

So if you were given a strategically critical project this year, i.e. the future P&L of the company depends on its successful implementation and return on investment, who would you trust to deliver it? Would you out-source it? Would you bring in contractors? Or would you give it to your own teams? I.e. Your own ‘machinery?’

If you wouldn’t give it to your people i.e. your brains, your machinery, what does that say about the state of your machinery and your ability to maintain it? What does it say about your capabilities for creating a team or organisation that meets the needs of the business?

Furthermore, what is the reason for not trusting your machinery with the job? Lack of knowledge? Lack of capability? Or lack of capacity?

Automation

Some of your competitors are now able to deploy enterprise-level, mission-critical applications on a daily basis. Through Continuous Delivery [1] (an encapsulation of many agile practices) the business can ask for a change, have it designed, developed, tested and deployed live, on an enterprise scale within 24 hours if required.

Test-driven development, continuous integration, automated acceptance testing, automated environment provision, automated configuration, automated load & performance testing, automated application and database deployments enable this capability…

Each of these individual innovations has removed many manual processes from the value stream of creating and delivering software, and the effect has been to rapidly reduce cycle time to market. These innovations implemented in concert, represent a fundamental shift in software development capability and capacity. Continuous delivery is starting to incrementally evolve business models.

But even accounting for this automation and reduced cycle-time, you still need people to establish and maintain that capability… The brains are the machinery, and are needed to write the automated tests, configuration and deployment scripts, to design the environments to be automatically provisioned and to establish the continuous integration process, as well as design and write the code.

And you’ll need resources to take you on beyond this point, adopting the next level of processes and technologies that drive the business forward in this ever-changing technology landscape.

Investment

So if the brains of your teams are the machinery of business, if technology is moving so fast, if you’re in a talent war and your people are implementing these technologies or assessing and integrating them… Do you really have the right level of focus on, and investment in the attraction, retention and development of your people?

Original post: http://businessvalueexchange.com/brains-are-machines-series-blog-1-shifting-sands/ The industrial revolution saw the landscape of Britain transformed from rural & agricultural to urban & industrial. The mass exodus of people from the country into the city represented a fundamental shift in the social fabric of the country.

The companies themselves were able to recruit and retain low-skilled workers, working on high-cost machinery that required constant maintenance and investment. The machines had maintenance schedules, were constantly oiled, monitored, measured, and had parts regularly replaced because they were the core contributor to the profitability of a company.

A worker leaving the company had little impact on the capability of the business to create its product.

The information age has brought with it a shift in power toward the knowledge worker due to the nature of work. The information worker is a higher-cost resource, holds more tacit knowledge and intrinsically more value to a business, as their knowledge is part of the whole make-up and fabric of a company. Put bluntly “their brain is part of the machinery”. And therefore a business has more reliance on its people as resources, rather than its machinery (or infrastructure).

A worker leaving the company has a larger impact on the capability of the business to create its product or service. Tacit knowledge is leaving the business, a new worker is required and their induction into the collective takes far longer and costs a lot more.

So if brains are the machinery of your company, what kind of shape are they in?

How much are you investing in them, what does their maintenance schedule look like?

The software industry has a scarcity of resource, and this scarcity of resource has existed for a number of years. In the manpower survey of 2012[1], 25% of EMEA employers reported difficulty filling jobs due to a lack of available talent. It has led to you being in a talent war, having to pay c20% fees for recruitment of team members before they’ve walked through the door. Also, your best ‘machinery’ is at risk of being head-hunted by the competition.

So if you’re paying c20% to a 3^rd party just to bring talent through the door, and your best talent is at risk of being pinched, how much should you be paying to develop and maintain that talent?

[1] Talent Shortage Survey 2012, Manpower Group

I’ve been invited to become a CIO Thought Leader and Featured Contributor on a new IDG produced site in collaboration with HP Enterprise Services. The site is called The Business Value Exchange and you can find out more about it here.

I’ve written a couple of blogs including a piece on the Cellular Business model and the start of a blog series entitled “Brains are Machines”.

I hope you enjoy the thinking!

The Cellular Business Model

Business in the 21^st century is fast-paced, our tools are the internet, the knowledge worker, internationalisation, globalisation, the PC, the cloud, digital communications, a networked global economy.

So why are our organisational structures and practices based on 200 year-old thinking?

The current hierarchical corporate structures that dominate our economies have been in place for over 200 years and were notably supported and defined by Max Weber during the 1800s. Even though Weber was considered a champion of bureaucracy, he understood and articulated the dangers of bureaucratic organisations as stifling, impersonal, formal, protectionist and a threat to individual freedom, equality and cultural vitality.

In the 21st century, and particularly in the software industry, we need to evolve. Hierarchical enterprise structures were requisite for the 19th century, should probably have evolved in the 20th century, and are certainly out of date in the 21st century. Enterprises today need to focus on creativity, speed to market, data, intellectual capital, technology adoption and agility.

When you consider the abundance of waste within large organisations – the bureaucracy, governance procedures, multi-layered management hierarchies, complexity, politicking, and size, it is abundantly clear why innovation is impeded. Organisations become slow to market, narrow in perspective, and are reduced to becoming dinosaurs awaiting oblivion… or merger, acquisition, management buy-out, government bail-out etc.

A more suitable model for organisations in the 21^st century is cellular in structure.

The entire organisation is a cluster, swarm, honeycomb of individual, autonomous teams of 6-10 members, with each team functioning as an independent profit centre. Companies achieving this cellular model would have the flexibility, adaptability, speed to market and open-minded perspectives required to function on a large scale in rapidly innovating markets.

Through the adoption of Agile & Lean Thinking, Open Book Management, Pattern Theory and Cloud Computing, we can see how an enterprise could exist as a swarm of multiple, independent, autonomous, profit-making entities.

Using Open Book Management, we provide each cell with a clear and unequivocal financial view of the cell, its costs and its expected returns. Principles and practices such as producing shippable product every iteration and the focus on product quality found within agile development, support rapid delivery cycles and speed to market.

We amplify the learning through the use of pattern language for software and organisational structures. The technology infrastructure for a cell to develop and distribute its software products on a global scale without significant capital expenditure, is afforded by the use of cloud computing. As the customer base grows, the ability to serve a wider audience increases on a transactional basis and with cloud technologies this enables a cell to respond effortlessly to elasticity of demand.

The business world is changing at a phenomenal rate, and yet our organisational structures and cultures are not responding or adapting quickly enough. Corporate strategy is no longer purely about research, analysis and long-term planning and investment, it is about making the business more able to cope with change. Our current “in-built” culture and mind-set of hierarchy and centralised command and control is no longer fit for purpose. Market share will be eaten away until more innovative thinking is applied to corporate structures, governance and operating models.

The Cellular Business Model achieves the level of adaptability and flexibility required to react to and exploit market opportunities in the 21^st century.

For a more details of the Cellular Business Model: www.cellularbusinessmodel.com

The Agile:MK Journal, Issue 04 March edition is available from www.agilemk.com.

This edition is a write-up of the March User Group session was a discussion about Writing Good Requirements.

This blog is part of the Blog Series: A Decade in Agile and was first published in February 2005. My updated reflections are in blue italics.

I believe that adopting a scrum approach to project delivery provides the following benefits:

• Higher levels of business buy-in
• Higher levels business involvement
• Clearer alignment of functionality to business value
• Higher levels of adoption
• Better ROI

Now... for clarity, I'd like to point out that I have created business cases before and hope I will continue to do so for agile projects. I've used ROI, with discounted cashflows, NPV and IRR and even the Benefits Management process designed by Cranfield Business School. But... often the traditional delivery approaches do not help the team to maintain a focus on the business case throughout the lifecycle of a project.

Often once the requirements have been stated, the business moves into the "pay and pray" stage, where they hope that in about 6 months time they'll get what they asked for. Agile approaches have in-built processes that ensure a constant focus on business value.

The assumption in my thinking at this time that I couldn’t see, was that a strong, intelligent, informed and networked Product Owner is directing, prioritising and developing the product backlog. In my earlier scrum projects the product strategies,owners and backlog were very clear and iteration was part of the process

Increasingly, the role of the Product Owner is becoming more demanding and important, I think there are a number of reasons for this:

• Agile teams are getting faster
• Sprints are shorter
• The scaling of teams is more prolific
• Teams are incrementing but not iterating

As teams get faster they create more demand on Product Ownership. More stories are required per sprint, more software is created for review and delivery. Couple this with shorter iterations of just 1 or 2 weeks and the Product Owner necessarily becomes a full-time role just to fulfil the artefacts and cadence of a fast team, regardless of managing product strategy, market analysis or customer analysis and feedback.

If we then add in the scaling of teams then Product Ownership necessarily becomes a team activity with Proxy Product Owners (or similar title) where the ‘delegation’ of business requirements definition and prioritisation is essential and suddenly we find ourselves moving swiftly back to ‘middle-men’ between the customer and the development team.

Of more concern to me is the increasing devaluation of iteration. I think here I ought to define what I mean. In a sprint, the team will take in stories as vertical slices of software to product a potentially shippable product. This slicing of software and delivery of pieces is what I refer to as incremental delivery.

Whereas, iteration for me, is the ability to return to a piece of software and evolve it, change it, adapt it, alter it, based on feedback from the business or customer. My current concern is that many teams are delivering in increments, but are not actively seeking the feedback from the customer/product owner and expecting to iterate upon the increment.

Rather, teams feel that they’ve got to get the increment right first time and are increasingly spending more time upfront to get things ‘right first time’ rather than using the more tangible medium of customer feedback to refine their product.

If this trend continues, teams will lose the benefits of agile working and will increasingly put more pre-sprint activities in place creating longer cycle times to market with less customer validation and poorer product.

and now I'll tell you how...
Scrum is focussed on delivering increments of shippable software every 30 calendar days (typically 2 weeks now). In my experience, the impact on the business stakeholders and user group of seeing quality software delivered every 30 days (one 30-day iteration is called a sprint) is immense... http://www.controlchaos.com/about/

Picture the scene... It's the programme kick-off meeting, the steering group, user group and entire programme team are assembled and you are presenting the project business case, objectives, structure, ways of working and plan. Then you say, "and the first delivery will be in 19 working days."
I was not short of a few sceptical faces that morning...

However, 19 days later, I was in front of the same audience showing the working software. Now we'd only built about 8 pages, but they were of production quality. The functionality enabled the user to search for and view product information and provided on-line help. This functionality was built using .NET technology integrating to an IBM AS-400 mainframe.

The impact of delivering this one "sliver" of production code was astounding. Suddenly the user group could see that we were really building this stuff straight away, and from the end of sprint 1 until live date, we had significant levels of business buy-in and involvement. Far more than I have ever experienced using traditional, waterfall methodologies.

Now scrum also uses a Product Backlog. A product backlog is a list of high level business requirements prioritised purely on a business value basis. So what's so new about that? ... Nothing.

What is new, is that because we are delivering full production code at the end of every sprint, we can measure our expected business return directly against cost far more precisely. AND... at this point assess the outstanding functionality, and either change direction, de-scope because the outstanding functionality has low business value, or continue with the project as it is.

This gives us clearer alignment of functionality to business value. Because of the incremental approach, the closure of requirements every 30 days, and the ability to more granularly relate business value to requirements, the value of the project is transparent to all stakeholders.

At the end of each sprint the sliver of functionality is made available to the business users to review and feedback on. Feedback is classified as an enhancement or bug, but the real value is that the business users are iteratively reviewing and directing the design of the solution as the project progresses. By the time the solution moves into production, potentially 8 months later, adoption levels are far higher than those of traditional project approaches.

Finally, scrum approaches give you a better return on your investment. Firstly, the teams are more productive see http://blogs.conchango.com/stevegarnett/archive/2004/11/19/297.aspx. But from a business perspective, the incremental completion of the highest priority requirements by the project team, means you will always be maximising your investment, because the team will always be building the stuff the business has prioritised as the greatest value.

In my experience, using scrum has really benefitted the business stakeholders because change is embraced, only valuable functionality is built (and this is picked by the business), and superfluous requirements are not built which reduces waste (Lean software development)

http://www.poppendieck.com/overview.htm

www.agilemk.com

Latest issues of Agile:MK Journal available.

Next Meeting: Tuesday 26th March, 6pm-8pm, Jurys Inn Hotel, Midsummer Boulevard, Milton Keynes