structure-2-182x182Agile methodologies claim to deliver many benefits. To seasoned executives and project managers, the benefits that are frequently claimed by ‘agilists’ appear however, to be too good to be true. There are many “war stories” of companies apparently achieving the “holy grail” of software product development and delivery: on time, in scope, in quality and on budget. Why then, if Agile makes this possible, are we not all doing it? It must surely be too good to be true, there must be something hidden, or something that isn’t being talked about.

 

Well… there is.

To have any chance of making the change to Agile truly successful and thus sustainable, it has to become part of the culture of the organisation. It is paramount therefore, to align not just engineers, business analysts and testers (which is the limit of many agile change programmes) but also to align the other interacting departments: from HR to Marketing and Management to Support and Partners to IT infrastructure and even the Client, whether internal or external. Thus, sending someone on a Scrum Master course and telling the delivery team that they are now going to be an agile team is the easy part. If the goal is a long-term sustainable change to create high-performing aligned teams, then far more needs to be done.

If this is not done, frustration will increase, communication will break down, trust will become distrust and ultimately the initiative will fail with consequences for the company as a whole. If this is not done, then the benefits expected from implementing an agile methodology will not be realized.

Want to Read the Full Story Offline?

et-download“Maximise Agile Alignment Across the Organisation” can be downloaded. Please provide your name and email and we will send you a PDF.

Your Name*

Your Email*

* = Required

Subscribe to Email List

captcha

More on Email Subscription

To keep our contacts informed and up-to-date, we send out monthly newsletters and occasionally announcements (no more than one a week). Once you provide your name and email address, we will send you an email to confirm. You can always unsubscribe at a later date by clicking the link embedded in the email. If you have any issues with this service, don't hesitate to contact us.

Wollen Sie die ganze Geschichte offline lesen?

et-download“Optimale Einbindung betroffener Unternehmensbereiche in den agilen Entwicklungsprozess” kann hier heruntergeladen werden. Bitte geben Sie Ihren Namen und Email. Wir schicken Ihnen dann die PDF.

Ihre Name*

Ihre Email*

* = Notwendig

Email-Liste abonnieren

captcha

Mehr über Email-Liste

Sodass unsere Kontakte informiert sind, schicken wir monatliche Newsletter und gelegentlich Ankündigungen (nie mehr als ein pro Woche). Sie können jederzeit zu einem späteren Zeitpunkt abmelden. Falls Sie Probleme mit diesem Service haben, stehen wir jeder Zeit zur Verfügung.

How Is the Rest of the Organisation Affected and Do They Know It?

The agile team needs to interact with non-agile teams, groups, units, organisations and companies. This includes, and is certainly not limited to, the Client, Senior Management, Human Resources, Sales and Marketing, Partners, Support and IT Services / Infrastructure. When the agile team is up and running, these parties all need to be involved with the change in order to become aligned.

The diagram below shows the Client as the highest block in a structure, supported by the agile team.  The agile team is supported by Sales, Partners and HR.  The agile team can of course work without one or two of the others but the structure is not optimised. IT Services / Infrastructure provide support to them all.  The whole structure’s foundation is of course, Senior Management.

Structure

The Client, whether internal or external, is the prime driver behind the needs of the market and time-to-market.  Agile concepts can be used to drive the Client to adopt new features quicker than ever, and thus reduce time-to-market, allowing Clients to leapfrog their competition. If this is not capitalised on, then possibly the greatest Agile value proposition will be missed.

In addition, isn’t it usual for clients to log defects into a “big black hole” with no feedback resulting in needless escalations through multiple management levels, on both sides of the relationship?

Careful use of the principals of agile development will address these points quite considerably. The client will want the software because they must have been involved in its continuous development, have helped it evolve and have seen live demonstrations at the end of every timebox.  Defects will be managed according to the timebox cycle, so feedback is always given within a short timescale and never longer than the length of the timebox.

 

Any organisation that has decided to adopt an agile approach should, rather must, have the backing of Senior Management. If not, the move will fail. Assuming however, that Senior Management support is secured, have they considered changing the way they work, or are they at least conscious of the “stand” that they will no doubt take that will conflict with agile principles. This includes command and control, influencing estimating, “I know better”, changing team members during a timebox, and wanting to evaluate and measure the performance of teams during a release.

Once reasonable levels of the above points are eradicated, Senior Management will quickly realise that they too are affected.  More specifically, management will be freed from firefighting and controlling.  They can look at growing the business: innovation, investment, sourcing, partnerships etc. Ultimately, they can concentrate on building equity value for the owners and shareholders.

 

The role of Human Resources is vital when adopting an agile methodology. Change is change.  People are affected; they become unsure, worried and fear for their position. It is now the team that is the primary focus, not the individual. Periodic reviews and yearly performance evaluations need to be adapted.  Some individuals, regrettably, cannot adapt.  They will need coaching ‘out’.

Does the organisation have a set of corporate values that describe the way to work or the desired attitude of workers? Does this still match?  How is diversity of the workforce affected, specifically the cultural backgrounds of employees?  Finally, how is recruitment adjusted to attract the correct talent?

HR needs to recognise they play an instrumental role in setting the foundations for high performing aligned teams and will need to act with urgency to address these and other staffing issues.

 

New market segments and prospects will drive the development of new products. Thus, the organisation’s front facing teams, primarily Sales and Marketing but also consultants, are key. They are the ones who talk to prospective clients and present the needs of the (new) market into the agile teams. This is therefore, an extremely important interface. Are they aware of how directly affected they are by the delivery team’s Agile move?

If the Sales team and others are not aware of how the delivery teams function and more importantly, the timebox cycle, then frustration and mistrust will prevail and alignment will remain a distant dream. The key to resolving this is to build trust in the relationship by proactively involving Sales and Marketing in the timebox cycle of the agile teams. Only then will they appreciate the work the agile teams do. Once that appreciation is apparent, Sales will do what they can to prevent prospective clients from demanding demonstrations of features in the middle of a timebox, which is very damaging to an agile team.

 

If the agile team works with external Partners, are they aligned? Are they agile-aware? Are they able to adopt at no extra cost? This is important because the Partner may not be agile aware and could expect their training costs to be covered.

The benefits of going Agile in an environment containing external partners are improved planning of key external resources and associated cost control. In addition, due to better planning, there is less risk associated with the partner re-assigning key consultants to other mandates.

 

In a typical IT organisation, the Support department is often an afterthought. Such individuals and teams are often the last to know what is in a release until a Client complains, at which point they get an email or worse, a direct telephone call. Additional issues include high turnover and low acceptance by other employees.

Given the chance, the Support department can influence the design of the product they are to support as they are the people with the most exposure to live client issues. Shouldn’t the agile teams be taking advantage of this experience? Shouldn’t the agile teams feel the client’s pain? Yet how can this be done?

Simple, bring the Support function into the agile team so that everyone benefits.

 

The agile teams are dependent upon system infrastructure (hardware and software). The IT Service teams can make the Agile move appear as if it is failing or stalling. Failure to assist IT Services support the agile teams is failure to optimise the environment in which the agile teams work.

Are the IT Service teams aware of the importance of their role in getting a product to market as soon as possible? For example, slow disks slow everyone down, at the cost of what, a few hundred dollars per workstation? Caution however, they need to plan well so as not to distract the focus of the agile teams away from new product development.

IT Service teams have the power to release frustration and raise energy levels within the agile team and across all members of every agile team.

 

The Client, whether internal or external, is the prime driver behind the needs of the market and time-to-market.  Agile concepts can be used to drive the Client to adopt new features quicker than ever, and thus reduce time-to-market, allowing Clients to leapfrog their competition. If this is not capitalised on, then possibly the greatest Agile value proposition will be missed. In addition, isn’t it usual for clients to log defects into a “big black hole” with no feedback resulting in needless escalations through multiple management levels, on both sides of the relationship? Careful use of the principals of agile development will address these points quite considerably. The client will want the software because they must have been involved in its continuous development, have helped it evolve and have seen live demonstrations at the end of every timebox.  Defects will be managed according to the timebox cycle, so feedback is always given within a short timescale and never longer than the length of the timebox.  

Any organisation that has decided to adopt an agile approach should, rather must, have the backing of Senior Management. If not, the move will fail. Assuming however, that Senior Management support is secured, have they considered changing the way they work, or are they at least conscious of the “stand” that they will no doubt take that will conflict with agile principles. This includes command and control, influencing estimating, “I know better”, changing team members during a timebox, and wanting to evaluate and measure the performance of teams during a release.

Once reasonable levels of the above points are eradicated, Senior Management will quickly realise that they too are affected.  More specifically, management will be freed from firefighting and controlling.  They can look at growing the business: innovation, investment, sourcing, partnerships etc. Ultimately, they can concentrate on building equity value for the owners and shareholders.

 

The role of Human Resources is vital when adopting an agile methodology. Change is change.  People are affected; they become unsure, worried and fear for their position. It is now the team that is the primary focus, not the individual. Periodic reviews and yearly performance evaluations need to be adapted.  Some individuals, regrettably, cannot adapt.  They will need coaching ‘out’.

Does the organisation have a set of corporate values that describe the way to work or the desired attitude of workers? Does this still match?  How is diversity of the workforce affected, specifically the cultural backgrounds of employees?  Finally, how is recruitment adjusted to attract the correct talent?

HR needs to recognise they play an instrumental role in setting the foundations for high performing aligned teams and will need to act with urgency to address these and other staffing issues.

 

New market segments and prospects will drive the development of new products. Thus, the organisation’s front facing teams, primarily Sales and Marketing but also consultants, are key. They are the ones who talk to prospective clients and present the needs of the (new) market into the agile teams. This is therefore, an extremely important interface. Are they aware of how directly affected they are by the delivery team’s Agile move?

If the Sales team and others are not aware of how the delivery teams function and more importantly, the timebox cycle, then frustration and mistrust will prevail and alignment will remain a distant dream. The key to resolving this is to build trust in the relationship by proactively involving Sales and Marketing in the timebox cycle of the agile teams. Only then will they appreciate the work the agile teams do. Once that appreciation is apparent, Sales will do what they can to prevent prospective clients from demanding demonstrations of features in the middle of a timebox, which is very damaging to an agile team.

 

If the agile team works with external Partners, are they aligned? Are they agile-aware? Are they able to adopt at no extra cost? This is important because the Partner may not be agile aware and could expect their training costs to be covered.

The benefits of going Agile in an environment containing external partners are improved planning of key external resources and associated cost control. In addition, due to better planning, there is less risk associated with the partner re-assigning key consultants to other mandates.

 

In a typical IT organisation, the Support department is often an afterthought. Such individuals and teams are often the last to know what is in a release until a Client complains, at which point they get an email or worse, a direct telephone call. Additional issues include high turnover and low acceptance by other employees.

Given the chance, the Support department can influence the design of the product they are to support as they are the people with the most exposure to live client issues. Shouldn’t the agile teams be taking advantage of this experience? Shouldn’t the agile teams feel the client’s pain? Yet how can this be done?

Simple, bring the Support function into the agile team so that everyone benefits.

 

The agile teams are dependent upon system infrastructure (hardware and software). The IT Service teams can make the Agile move appear as if it is failing or stalling. Failure to assist IT Services support the agile teams is failure to optimise the environment in which the agile teams work.

Are the IT Service teams aware of the importance of their role in getting a product to market as soon as possible? For example, slow disks slow everyone down, at the cost of what, a few hundred dollars per workstation? Caution however, they need to plan well so as not to distract the focus of the agile teams away from new product development.

IT Service teams have the power to release frustration and raise energy levels within the agile team and across all members of every agile team.

 

Conclusion

Changing a development team of business analysts, engineers and testers into an agile team is easy.  Realising the full potential of high-performing teams in an agile environment however, requires alignment across the organisation.  The level of alignment across the organisation is directly proportional to the level of benefits realised from the move to agile.  The greater the effort to align the organisation, the higher the increase in morale, energy levels and company-wide teamwork and lower frustration levels!

Only when the organisation is aligned, will the Agile adoption become culturally sustainable for the long-term.