Skip to content

Agile a State of Mind for the Organisation, Not Just a Development Methodology (Part IV)

Compared to other software development projects, CMS implementations typically impose greater risk on organisations; because of the role CMS plays in managing some of their most valuable assets, their data. With CMS business workflows running through the heart of an organisation, CMS implementations offer unique challenges. In an attempt to address many of the widely documented risks and challenges, organisations are turning to Agile methodology, rather than staying with traditional plan-based project methodology to manage their implementation. However, as this article shall discuss, many organisations are failing to recognise that Agile is a state of mind for the organisation, not just a development methodology. To ensure a successful Agile led CMS implementation they must make the appropriate organisation-wide changes and not consign Agile solely to software development activities.


Figure: Agile Adapt (Review, Reboot & Improve)

Accelerating an organisation’s adoption of Agile on a CMS implementation occurs in two ways. The first is to advise the organisation on the most appropriate pilot project to use. The second is the incremental development and implementation performance (i.e. improvement from Sprint to Sprint and Project to Project). This ensures the business change programme efficiently and appropriately selects and then adopts Agile across its various types of projects. Successful business change programmes promote appropriate best practices, by providing cost effective access to subject matter expertise tailored to their project. The framework also guides stakeholders through a series of review, reboot and improve plans applicable to their circumstances.

Once an agreed business unit baseline capability has been reached during the Agile Adoption Phase, the organisation is ready to select the projects that will initially adopt Agile methodology. It is important to recognise that Stage 2, must span all five business units. The overall organisation success is determined by the collective performance of all the business units operating to the Agile philosophy.


Figure: Agile Led CMS Framework Stages

During Stage 2 the Agile change programme framework provides access to the appropriate subject matter expertise in the form of preconfigured schedules, tailored benchmark audits, analysis tools and predefined best practices. Each business unit is granted access to the appropriate support, guidance and intellect as it engages with the programme.

Five Business Units

4.1 Marketing
The Marketing business unit performance capability is a measurement of individual or collective offering success, in particular, the overall return on investment of products, services or solutions within a defined period.

With the adoption of Agile a number of important changes are also required within the marketing business unit to ensure delivery of organisation-wide success.

As the Product Owner plays a central role throughout an Agile project, it is critical that the changes:
- help them establish viable project business cases without the traditional upfront agreed set of deliverables and wealth of financial and technical documentation.
- enhance their ability to accurately capture and analyse market requirements.
- allow the Product Owner to engage with the customer base on a frequent basis to gather feedback on each sprint deliverable.

Therefore, the primary marketing organisation changes necessary to support the Agile change programme are organisational communication, financial and legal management, plus organisational innovation.

4.2 Engineering
The Engineering business unit performance capability is a measurement of project milestones completed on time, to specification, and within budget. The successful application of a Agile change programme will ensure the engineering business unit accurately captures the appropriate engineering data to report on its performance capability at a number of levels, e.g. milestone, project and period.

The Agile change programme framework is an innovative and streamlined procedure, which changes the way the engineering business unit operates. Emphasis is placed on understanding goals and objectives rather than detailed specifications. It is critical that the changes to this central function should include:

- an organisational environment which fuels open and frequent discussion / collaboration between all stakeholders.
- access to simple IT tools that record and broadcast concisely short term project deliverables.
- access to the appropriate facilities to hold daily progress meetings, group planning sessions.
- access to the appropriate facilities to hold monthly performance evaluation sessions (e.g. sprints and retrospectives).

As a consequence the primary organisation capabilities that require care evaluation and optimisation from a engineering business unit perspective are organisational communication, facilities, resource management and organisational innovation.
4.3 Sales
The Sales business unit performance capability is a measurement of how many qualified sales opportunities are converted to actual orders (i.e. Won/Bid= %)

The flexibility of the Agile Manifesto appeals to the Sales business unit, as it promotes flexibility allowing the organisation to pursue sales opportunities without a lengthy bureaucratic process or jeopardizing the Agile change programme.

For the sales business unit to exploit the opportunities offered by the Agile change programme framework a number of important requirements need to be met, including:
- open and honest collaboration between the engineering, marketing and engineering business units.
- awareness of the current project scope and timeline (i.e. sprint).
- an ability to quickly quantify the sales value of individual qualified sales opportunities.
- an ability to quickly quantify the cost of implementation.
- quickly relaying changes to the market.
- assess the impact on medium to long term income.

4.4 Services
The Services business unit performance capability is a measurement of project milestones completed on time, to specification, and within budget.

Agile methodology can be applied to IT service delivery projects in exactly the same way as internally development software and therefore, shares the same four key changes as Engineering.

4.5 Support (Customer Services)
Typically the Support business unit performance capability is a measurement of the average length of an open support call. The Agile change programme provides an opportunity for this business unit to exploit its direct communication with the customer base and its indepth understanding of their operations to:

- improve the development of stories.
- participate in sprint evaluations.

- release readiness via testing participation.
- draw attention to hot topics.

With the appropriate changes to their processes the increased participation by the Support business unit will increase product quality, which in turn will drive down the average length of open support calls.

2012 02 06 John E. Abram Enterprise Agility
Organisational Agility Comments (0) Permalink

Agile Team: Roles & Responsibilities Explained

At the turn of the New Year I was invited by a Hi-Tech organisation to provide a couple of days Agile consulting to their core project team. The background was straightforward enough. Approximately 12 months ago, they started to adopt Agile on a small number of projects, but hadn’t really seen any benefits. Commercial pressures were constantly disrupting software development.

Armed with a box full of the usual Agile artefacts (i.e. post it notes, blue tack and A5 index cards), I had arranged to meet with the first of two groups of eight (16 software engineers and testers) in the morning and repeat the session in the afternoon. The topics covered during session one were:

I. Business Needs & Stakeholders
II. Epics & stories
III. Sprint planning.

The second session scheduled for the following day focussed on:
I. Daily Scrums
II. Retrospectives
III. Sprint deliverables.

Business Needs & Stakeholders
Using a very simply example, booking a holiday, I walked the group through the main activities of defining their objectives and constraints, identifying who the main stakeholders were (i.e. kids and wife), and documenting a series of high level needs (e.g. travel time must be no more than eight hours, North America was preferred, camping was more appealing then staying in a hotel, total budget must not exceed €2,000 and we wanted to spend more than two weeks during July, but not more than three). I explained that these were our business needs that had to be defined by the stakeholders.

What was clear from the workout was that the client had not understood the difference between a business need and a story. In fact, because of the way they had organised their sprint activities, they were holding a high planning session each week, which was attended by the CEO through the organisation to system testers. As a result, what they had actually done was combine product backlog development sessions with sprint planning sessions. This was leading to a confusing state of affairs and no clarity would emerge.

Recommendation 1: Roles and Responsibilities

After explaining the roles and responsibilities of the Board, senior management and product owners (they own the backlog and are responsible for its constant upkeep), we made some progress in drawing a clear separation between product backlog facts and potential epics and stories. The following hierarchy proved a useful tool to explain the underlying concepts.

Figure: Hierarchy Model

Recommendation 2: Differentiating the Whats (what it should do or be) from the Hows (how it should do it)

I explained that the ‘Whats’ emerge from a continuous dialogue between the business leaders, stakeholders and the product owner, who oversees the sessions. Transforming the first three layers in the hierarchy structure above is a continuous process that occurs outside the regular Sprint Planning Sessions.


Figure: Business Needs to Stories

To provide the entire organisation with a ‘single point of truth’, i.e. what are the current priorities and what else is on the backlog, I couldn’t stress enough the value in producing a product backlog wall mosaic. The product backlog wall would consist down the left hand side the high-level stakeholder needs. If they wanted to continue managing everything within their own bug tool, then they should at least consider printing out the list and pasting it in the wall on a regular basis.

What’s the difference between stakeholder needs and ‘epics & stories’ was a common question, which I will answer a few paragraphs down.

Recommendation 3: Agile methodology is an Organisational Methodology (not just a Software development methodology)

Raise the awareness of Agile methodology across the whole organisation, especially sales, who were the main source of sprint disruption. Agile is their friend! I have long advocated that Agile methodology is not just for the Software function (circ 2009, published the Monetical Agile Framework). When Agile is clearly understood by the entire organisation, a better business cycle is found between those that manage the externalities (e.g. commercial life cycle) and those that take care of internalities (e.g. software development cycle).

As is common within many highly competitive markets, the sales organisation are constantly pressed to deliver the latest new feature to the customer in order to keep them happy, beat competitors or address a newly discovered weakness (aka defect).

Figures: Functional Cycles
It was therefore agreed that every effort would be made to raise the aware of Agile methodology amongst the Commercial Life Cycle teams. For example, initially attending the same 2 sessions.

Tagged
2012 02 02 John E. Abram Enterprise Agility
Organisational Agility
Roles & Responsibilities Comments (0) Permalink

Open Stories™: DocBook Transformation. An Emerging Example

Hello, over the course of the next few months I pan to provide running commentary on a new and exciting project at the NHS. Transforming 1,000+ individual pieces of Alfresco content into DocBook V5. To give structure to my commentary, I will do my best to provide a summary of each Sprint and the core technical and commercial challenges and benefits. I hope you enjoy following our progress. It is our aim to convert all our unstructured project experience into a repository of structured knowledge, which we shall share with the entire Alfresco Community as a series of Open Stories™.


Sprint 0 Business Case & Project Objectives
Today we start a new and exciting project at the NHS Institute, a DocBook Transformation capability, which we intend to share fully with the Alfresco Community as a new Open Project. (see: hyperlink bog lost Open Project Explained).
The client has two overriding objectives that require them to transform all their content into an open standard:

• the need to ensure their data (prized IP) is stored in a non-proprietary format, such that it could be easily read some 20 years from now; i.e. they don’t want to have to locate a copy of a Office 2007 license to be able to view one of their documents.
• the opportunity to re-purpose much of the content (re-purpose for reducing duplication and identifying and promoting standard text, e.g. company or service description) rather than several individuals producing content on the very same topic of varying detail.

Sprint 1 Transformation Design
Today, there are approximately 1,000 documents (mainly in PDF and PPT format) requiring conversion. Each document contains between 50 and 100 pages each, therefore the overall transformation pipe line is looking at processing between 50,000 and 100,000 pages. Yet, they have been created with very little attention in the way of templates. In the past, more attention was given to developing a strategy that would reduce the number of document versions, so that a robust and reliable transformation pipeline would function. It would, ultimately, reduce the processing effort requirement on Alfesco and keep the code base to a minimum, ensuring future upgrades and hardware costs were capped.

DocBook will be performed in two steps:
1. Conversion to a single Microsoft Office Word 2010.
2. Transformation of each Word 2010 to DocBook V5.

Figure: Content to DocBook Transformation Pipeline

2012 02 02 John E. Abram Body of Knowledge Comments (0) Permalink

Agile a State of Mind for the Organisation, Not Just a Development Methodology (Part III)

Compared to other software development projects, CMS implementations typically impose greater risk on organisations; because of the role CMS plays in managing some of their most valuable assets, their data. With CMS business workflows running through the heart of an organisation, CMS implementations offer unique challenges. In an attempt to address many of the widely documented risks and challenges, organisations are turning to Agile methodology, rather than staying with traditional plan-based project methodology to manage their implementation. However, as this article shall discuss, many organisations are failing to recognise that Agile is a state of mind for the organisation, not just a development methodology. To ensure a successful Agile led CMS implementation they must make the appropriate organisation-wide changes and not consign Agile solely to software development activities.

Agile Adopt (Assess, Understand & Implement)

The first stage of the Agile Led CMS Implementation Framework focuses on clearly setting out an organisation’s business objectives supported by a business case for i the CMS investment, ii. the adoption of Agile and iii. the specific adoption of Agile on a single CMS implementation. In addition the organisation needs to run a series of short-focused pilots that assess, understand and implement the capability starting point (baseline capability).

Project Owners of Agile adoption and CMS must recognise that it requires more than just the Engineering resource investment. To reduce costs and increase the revenue of an organisation through the adoption of Agile requires involvement and commitment from business functions across the entire organisation.

Figure: Agile Led CMS Framework Stages

Successful change programme frameworks help organisations establish how prepared they are to adopt Agile, by measuring, planning and changing 10 individual key organisation characteristics (org. innovation, org. communication, knowledge mgt, facilities mgt, operational mgt, sourcing mgt, commercial execution, resource mgt, customer services, financial & legal).

Figure: Stage 1 – Programme Evaluation – Organisation Characteristics

Agile specific benchmark audits that leverage subject matter experts, accurately report how well each of these 10 organisation characteristics potentially meet the Agile Manifesto. Where discrepancies are found the integration of root cause analysis capabilities and a repository of best practice guidelines (proposed corrective measures) enables the framework to ensure organisations quickly address operational and commercial weaknesses whilst promoting best practices.

2012 02 01 John E. Abram Enterprise Agility
Organisational Agility Comments (0) Permalink

Our Open Project Philosophy Explained

At Monetical we’re fully committed to granting Alfresco project owners unrivalled access to the right resources to help them implement Alfresco using Agile methodology. A cornerstone of this philosophy is the capture of current unstructured project experience and it’s transformation into structured project experience before being republished to the Alfresco community. And all completely free of charge.

Introduction

Open Source is driven by a community philosophy and collaboration which leads to better software code emerging. Monetical extends this to include project implementation, i.e. the actual project management activities and the solutions that emerge. This results in working features and capabilities, which until now could only be acquired at considerable cost from 3d parties, e.g. system integrators. The Monetical for CMS™ body of knowledge is the home for this structured experience. Three types of body of knowledge exists, Open Source, Open Stories™ and Open Solutions™ each incorporating the value of the previous one and moving closer towards providing a fully functioning content management system build on Alfresco.


Figure: Open Project Components

Open Source

Open Source body of knowledge is housed within the Monetical Source and Revision Control System (i.e. SVN) and contains the actual source code, which has been written and certified for production from past projects by Monetical Consulting Staff or its clients. A source code and a free of charge SVN account is provided to each registered Monetical for CMS account, therefore removing the need for organisations to invest in their own software code management system for a potentially highly distributed and hybrid project team.

Open Stories™

The Open Stories™ is the second largest volume of body of knowledge available free of charge within Monetical for CMS. As the figure above indicates four components make up each Open Project.

1. Structured Project Experience

The main component of the Open Stories™ is the past structured experience, which is provided in the form of a hierarchy collection of tasks (coding, reach, admin and documentation) that all relate to the successful implementation of a Story, e.g. PDF Generation. The true value of these Work Packs is the associated project implementation estimates that accompany the individual tasks. No longer are project teams faced with devising their own implementation breakdown. Individual tasks are also supplied with links to associated information, i.e. previous decisions and guidelines, which are held in wikis.

2. Best Practices

The ability to constantly health-check your Alfresco implementation for both the way you’re adopting Agile and hopefully, exploiting Alfresco recommendations (e.g. database configurations) could not be easier. A comprehensive repository of preconfigured checklists, surveys and guidelines allow project owners to rapidly measure their capability, analyse their results and plan the most appropriate corrective measures to deal with short term risks within the current project and correct long term enterprise challenges for future projects.

3. Community Support

At Monetical we recognise Alfresco implementations can be challenging, and with a vast amount of unstructured information out there on the web, you can spend hours, possibly days tracking down the right piece of information to solve a particular implementation challenge, understand in greater detail a core Alfresco feature or how best to employ Agile methodology on your project. The Community Support feature ensures that this vital source of information either created from existing Monetical for CMS led projects or the wider Alfresco community undertaken by other project teams is available in an efficient manner to Monetical for CMS users. The Community Support feature is also a significant contributor to the body of knowledge providing on demand support where necessary in a directly, organised and easy to access format.

Open Solutions™

Monetical for CMS free of charge Open Solutions are a true cost alternative to purchasing 3rd party software licenses. On a regular basis Monetical audit their Open Project repository to establish the most common Open Project collections. Furthermore, Monetical consolidates their body of knowledge to define production quality solutions that are a true competitor to 3rd party offerings. Before being published to the Community via the Monetical for CMS, Test Scripts and Documentation are created and added to Open Projects, which allows individual project owners to rapidly deploy each solution within their own Alfresco implementation with just customisation and no further software development.

1. Test Scripts

The Monetical for CMS Test Scripts exploit Apache JMeter, a Java desktop application designed to load test functional behaviour and measure performance. Each published Testing Strategy document is accompanied with the associated JMeter test scripts (XML config files). Thus saving each project valuable time and helping the community develop a set of best practice testing scenarios.

2. Documentation

Where necessary the Monetical team has produced End User and Technical Documentation in the form of a Wiki, which enables constant improving, by allowing new authors and reviewers to make a contribution.

3. S&M Agreements

To provide long-term support that protects the organisation’s future upgrade costs Monetical offers for a small annual fee Support & Maintenance agreements. Under the terms of these Support & Maintenance agreements, Monetical certified staff will perform the associated upgrades with each major Alfresco release.

4. 3rd Party Licenses

In some instances it has proved more efficient to license 3rd party tools and products to deliver additional robust and fully rich functionality. To complement the appropriate 3rd party licenses, associated Work Packs, Documentation and Test Scripts are also provided.

2012 01 10 John E. Abram Accessing Experts
Body of Knowledge Comments (0) Permalink

Formal Agile Project Communication Timeline

One of the biggest challenges for managers is how to maintain effective communication, both within their own organisation and outside. While this is true of all organisations, we know that organisations embarking on an Agile led Alfresco implementation operate in particularly demanding environment.

Some of these demands are:

    turbulent and highly competitive labour markets
    rapid growth and change in project teams, with the need to bring new members up to speed quickly
    flexible and intensely networked organisation structures
    multiple knowledge-intensive communities running simultaneously, demanding the integration of specialist capabilities
    multi-location and virtual team-working and multi-cultural, multi-language environments

For Alfresco projects to perform at an optimum level, they must first understand the influences the key characteristics of the communication techniques and practices they employ during the planning, engineering, delivery and support phases. This greater understanding, coupled with a capacity to reflect on communication processes and outcomes, should be exploited to improve communication throughout the project.

Communication within the Alfresco project team, between the project team, its clients and future Alfresco users, suppliers and partners, stakeholders and management and the wider marketplace, is influenced by the team’s choice of communication channel, ownership, content and frequency.

Communication Owner
The individual responsible for crafting the message and ensuring the appropriate communication channel and timeframe is adopted.
Communication Content
Formal or Informal. Communication should be free of errors. Project plans should be written in a narrative form with a combination of text, graphical, tabular and other associated content types.
Communication Channels
The types of channels e.g. meetings, email, telephone, face-to-face, meetings or forum (e.g. wiki or wall). The Agile led Alfresco implementation Sprint Wall is a great solution for this. It provides everyone with a clear understanding of the current project status, ownership, issues and short-term objectives of what the project team is working on.

Communication Frequency
The frequency of communication within an Agile led Alfresco implementation must take into account the sensitivity of the information being communicated, whether the information is shared formally or informally, what the desired response or reaction time should be expected or required, and whether the information being communicated goes beyond the project team. For these reasons we have settled on 4 frequency types, I. Real-time, Daily, Weekly or Sprint, or As Needed.

Importance of Communication in Agile projects
Agile led Alfresco implementation success depends heavily on effective communication. As the Agile Manifesto states “greater reliance on communication rather formal documented processes and large specifications” are a key characteristic. Communication is rapid, focused and decisive within an Agile project team. Whilst formal communication occurs each day during the daily Scrum when the team reports project status and highlights challenges or issues, because the focus is on the completion of a single task, the entire team is tasked with helping remove the blocker before the project moves on to the next objective. The impact such project activities have on the wider project community needs to be considered. Communication must be clearly defined to ensure efficiency and that it doesn’t lead to multiple, and often confusing, messages which reaches a large number of people.

Project Communities
At the start of each project, I encourage project owners (Product Owner/Scrum Master) to identify everyone within their value chain that has a stake or interest in the project. Then, using a simple spreadsheet, assign their membership to one of the communication communities below. The spreadsheet then acts as a simple checklist – each time information needs to be circulated.

My primary Agile led Alfresco implementation communication communities are:

    Internal (project teams, internal departments or internal functions)
    Stakeholder (the above, plus stakeholders and management)
    Organisation (the above plus, all internal communication)
    Customer (the above plus, existing or planned Customer community)
    Suppliers & Partners (the above plus 3rd parties who are contributing to the project)
    Market place (the above plus, potential Customers i.e. Future users of the solution)

Tagged
2012 01 04 John E. Abram Communication Comments (0) Permalink

Agile Adopt (Assess, Understand & Implement)

Compared to other software development projects, CMS implementations typically impose greater risk on organisations; because of the role CMS plays in managing some of their most valuable assets, their data. With CMS business workflows running through the heart of an organisation, CMS implementations offer unique challenges. In an attempt to address many of the widely documented risks and challenges, organisations are turning to Agile methodology, rather than staying with traditional plan-based project methodology to manage their implementation. However, as this article shall discuss, many organisations are failing to recognise that Agile is a state of mind for the organisation, not just a development methodology. To ensure a successful Agile led CMS implementation they must make the appropriate organisation-wide changes and not consign Agile solely to software development activities.

The first stage of the Agile Led CMS Implementation Framework focuses on clearly setting out an organisation’s business objectives supported by a business case for

  1. the CMS investment,
  2. the adoption of Agile
  3. the specific adoption of Agile on a single CMS implementation.

In addition the organisation needs to run a series of short-focused pilots that assess, understand and implement the capability starting point (baseline capability).

Project Owners of Agile adoption and CMS must recognise that it requires more than just the Engineering resource investment. To reduce costs and increase the revenue of an organisation through the adoption of Agile requires involvement and commitment from business functions across the entire organisation.

Figure: Agile Led CMS Framework Stages

Successful change programme frameworks help organisations establish how prepared they are to adopt Agile, by measuring, planning and changing 10 individual key organisation characteristics (org. innovation, org. communication, knowledge mgt, facilities mgt, operational mgt, sourcing mgt, commercial execution, resource mgt, customer services, financial & legal).

Figure: Stage 1 – Programme Evaluation – Organisation Characteristics

Agile specific benchmark audits that leverage subject matter experts, accurately report how well each of these 10 organisation characteristics potentially meet the Agile Manifesto. Where discrepancies are found the integration of root cause analysis capabilities and a repository of best practice guidelines (proposed corrective measures) enables the framework to ensure organisations quickly address operational and commercial weaknesses whilst promoting best practices.

2011 12 09 John E. Abram Organisational Agility
Uncategorized Comments (0) Permalink

Agile a State of Mind for the Organisation, Not Just a Development Methodology (Part II)

Compared to other software development projects, CMS implementations typically impose greater risk on organisations; because of the role CMS plays in managing some of their most valuable assets, their data. With CMS business workflows running through the heart of an organisation, CMS implementations offer unique challenges. In an attempt to address many of the widely documented risks and challenges, organisations are turning to Agile methodology, rather than staying with traditional plan-based project methodology to manage their implementation. However, as this article shall discuss, many organisations are failing to recognise that Agile is a state of mind for the organisation, not just a development methodology. To ensure a successful Agile led CMS implementation they must make the appropriate organisation-wide changes and not consign Agile solely to software development activities.

The Need for an Organisation-wide Agile Framework
Within an increasingly unpredictable business environment, Agile development methodology aims to deliver increased business value from engineering (i.e. software development and implementation), whilst placing a greater emphasis upon people within the entire organisation and their creative abilities and teamwork ethic.

Agile methodologies generally promote:

  • active participation of stakeholders on a daily basis.
  • a leadership philosophy that encourages team work.
  • self-organisation and accountability.
  • a project lifecycle that encourages regular inspection and adaptation of how the team work
  • a set of engineering best practices that allow for repeated rapid delivery of high-quality software.
  • a business approach that aligns development with customer needs and company goals.

    • Not only do these techniques apply to the engineering team but, as I shall demonstrate, should be applied to the wider organisation. Consequently, encouraging collaboration and input between the software implementation team with other organisational departments such as Sales, Finance, Marketing and Customer Service becomes a must.

    The Agile manifesto states that organisations should focus on four core values:

  • Responding to change over following a plan.
  • Customer collaboration over contracts negotiation.
  • Working software over comprehensive documentation.
  • Individuals and interactions over processes and tools.

    • Business change programmes, like the adoption of Agile led CMS, should develop an integrated and organisation-wide approach that helps the business achieve its strategic goals. It is important to have a clear set of business objectives as part of a business case that combines Agile adoption and CMS investment. With these clearly defined, the business is in a position to predict, agree and measure the benefits from any such change. Therefore, organisations should seek guidelines, tools, support and experience to help them complete this critical business change.

    The problem organisations face when embarking on Agile adoption is the increasing amount of descriptive unstructured information about Agile methodology available from the Internet and books to training courses and blogs. While these sources usually focus on the engineering functions, providing running commentary on individual activities and processes, they fail to sufficiently detail the order of adoption. Furthermore, as the article has highlighted, they tend to omit other crucial functions such as Marketing, Sales or Customer Services. This, ultimately, leads to a poorly adopted Agile change programme.

    Unfortunately, when CMS implementation owners decide to adopt Agile they have difficulty discovering how best to exploit the wealth of information freely available, and in the majority of cases appoint dedicated external Agile experts, who embed themselves within the organisation for a period providing relevant training and coaching. A far more cost effective approach is leveraging a suitable business change framework, like the one that is integrated into Monetical for CMS. Frameworks, as well as granting access to the right Agile experts, should recommend the necessary guidance and measurement tools to steer an organisation through the key change programme stages.

    Typically, failure to exploit a framework for the transformation from a plan-based model to Agile occurs only within the engineering functions of the organisation. And 99% of the information published about the adoption of Agile assumes the organisation is an encapsulated green field site, which is not an accurate reflection of the current software industry. This unfortunate assumption gives further weight for a structured approach. A framework providing a structured approach would take into account such factors as, scope and diversity of the project (i.e. lifecycle), roles and responsibility, integration of dept business processes, customers and most importantly the rest of the organisation with whom it must work, depend and demonstrate CMS progress.

    To enable business change, owners need to accurately evaluate the progress of their Agile adoption beyond software engineering as they embark on their CMS implementation. A basic framework supports a number of techniques that capture, analyse and present how the change programme is impacting the organisation. Effective frameworks describe and recommend tools and applications that can be used to manage the change. The very best frameworks also help identity risk and best practices which in turn steers the organisation through the major challenges whilst taking into account specific business needs.

    Agile Business Change Stages
    In my view, a successful Agile business change framework must have three change stages (see figure below). Together the stages form a lifecycle ensuring the adoption of the appropriate core Agile principles and techniques at certain stages and avoids adopting arbitrary Agile techniques (e.g. scrum meetings, retrospectives) on disparate projects without understanding the interdependencies and their importance across the organisation.

    Figure 1.1: Agile Led CMS Framework Stages

    As the organsation works through the framework, monitoring the progress of the Agile led CMS project is achieved by evaluating how the organisation as a whole has adopted core Agile principles and techniques. A simple quantitative assessment of data collected about the business change programme achieves this (i.e. best practice assessments in the form of checklists and surveys). Furthermore, analytical tools associated with the assessment activity should be accessible to help the inexperienced team identify, diagnose and solve problems with the most suitable corrective measures. Throughout the programme, performance should be constantly benchmarked against the existing ‘current plan-based’ approach, the ‘Agile manifesto’ and industry best practices.

    Stage 1: Agile Adopt
    The first stage on the Agile Led CMS Framework focuses on clearly setting out an organisation’s business objectives supported by a business case for I. the CMS investment, II. the adoption of Agile and III. the specific adoption of Agile on a single CMS implementation. And the organisation is appropriately prepared by carrying a series of short-focused pilots that assess, understand & implement a capability starting point (i.e. their baseline capability).

    Stage 2: Agile Adapt
    Accelerating an organisation’s adoption of Agile on a CMS occurs in two ways. The first is to advise the organisation on the most appropriate pilot project to use. The second is the incremental development and implementation performance (i.e. improve from Sprint to Sprint and Project to Project), ensures the business change programme efficiently and appropriately selects and then adopts Agile across its various types of projects. Successful business change programmes promote appropriate best practices. By providing cost affective access to subject matter expertise and taking into account the project, the framework helps guide stakeholders through a series of review, reboot and improve plans applicable to their circumstances.

    Stage 3: Agile Scaleout
    Having adopted Agile development as the standard across the organisation, the third stage helps the organisation optimise their Agile project life cycle capability and look at ways to increase governance, apply the right level certification and measures to control scale-out. Collectively, this is referred to as Agile Quality Assurance. Providing guidance on how best to capture and exploit the experience from past projects across the three types (i.e. green field, major upgrade and minor upgrade) helps organisations identify performance challenges, uncover underlying operational and commercial weaknesses and the identification and promotion of best practices. All of which are designed to ensure the organisation’s Agile capability is constantly refractored to retain an optimum level of performance as the organisation matures.

    2011 11 30 John E. Abram Organisational Agility Comments (0) Permalink

    Agile a State of Mind for the Organisation, Not Just a Development Methodology (Part I)

    Compared to other software development projects, CMS implementations typically impose greater risk on organisations; because of the role CMS plays in managing some of their most valuable assets, their data. With CMS business workflows running through the heart of an organisation, CMS implementations offer unique challenges. In an attempt to address many of the widely documented risks and challenges, organisations are turning to Agile methodology, rather than staying with traditional plan-based project methodology to manage their implementation. However, as this article shall discuss, many organisations are failing to recognise that Agile is a state of mind for the organisation, not just a development methodology. To ensure a successful Agile led CMS implementation they must make the appropriate organisation-wide changes and not consign Agile solely to software development activities.

    Reducing Senior Management’s Heart Rates Everywhere

    When an investment in a core technology like CMS is made, expectations are always running high and so are nerves, especially when it represents a technology shift (i.e. greenfield site or from one vendor to another). Having invested months evaluating different technologies (e.g. Documentum, Alfresco, SharePoint) followed by a pilot programme (implementing a few core features), Senior Management make their selection and place an order. Whilst the implementation owner considers which staff to appoint to the team (i.e. upskill in house staff, appoint a traditional system integrator or hire a small number of independent contractors), the choice of software development methodology will commence.


    Figure: Senior Management Heart Rate Patterns

    As the chart reflects, the decision to adopt Agile methodology, initially increases the heart rate of Senior Management. However, as the initial project iterations (sprints) focus on delivering ‘some’ working code much earlier in the project lifecycle (compared to traditional plan-based projects), heart rates start falling much earlier, giving confidence in their technology and software development choices.

    When Senior Management adopt a traditional plan-based methodology, one that calls for the upfront production of a number of specifications, (e.g. business plans, roadmap, technical requirements, user interface designs, architect etc), questions will remain unanswered about the power of the new CMS and whether it the right choice. This is due to the length of time for these specifications to be completed, and only once completed can the development of code commence, which in turn can take several more months for demonstrable code. Throughout this time the heart rate of the Senior Management and the team remain high.

    Where Agile has been employed, heart rates reduce much quicker. Emphasis on working code over documentation enables the Senior Management to quickly demonstrate some core features to Stakeholders and the wider organisational community, proving that their choice of CMS was correct. However, combining an important CMS implementation with the adoption of Agile methodology has its own risks. It is here where a well structured business change framework is needed, taking operational and commercial factors in equal measures, whilst steering the programme leaders through the necessary evaluation, adoption and optimisation stages as CMS implementation meets Agile adoption across the entire organisation. Before exploring in greater detail the characteristics of such an Agile Led CMS Implementation Framework, it is also worth referencing the previously unrecognised implementation benefits of adopting Agile methodology for CMS implementations. In particular, the exploitation of standard work packs across a designated community, as per my National Computer Centre article,
    Getting the Knowledge, published in May 2011.

    Tagged
    2011 11 19 John E. Abram Organisational Agility Comments (0) Permalink

    Welcome to Monetical CMS – Agile adoption and Alfresco implementation

    The aim of this blog is to share with my own observations, facts and suggestions that relate to the successful adoption of Agile on Alfresco implementation projects and highlight how our unique System Integrator Portal – Monetical CMS can help in this process and the effective implementation of your Alfresco CMS.

    Learn more at www.monetical.com

    2011 11 04 John E. Abram Welcomes and Hellos Comments (0) Permalink