Tag Archives: Agile Transformation

How HR Can Save or Destroy Agile

“Business engagement alone is a necessary but not sufficient condition for Agile to succeed”

It’s taken a while but now it’s well understood amongst seasoned Agile practitioners that Business engagement is necessary for successful Agile implementations. Just when we thought engaged Business owners were enough, we’re now realizing Business engagement alone is not sufficient. The impact of corporate shared services, especially Human Resources (HR), on Agile adoptions or transformations are often overlooked. In fact, Agile practitioners often bypass HR in their zeal to quickly change the way they work and the related people processes.

“Companies are running 21st century businesses with 20th century workplace practices & programs”

– Willis Towers Watson

It’s not just IT departments practicing Agile but 21st century businesses overall that are characterized by flatter organizations and an insatiable appetite for small ‘a’ agility. Agility that is pushing and breaking the envelope of current HR processes and tools. Agile individuals and teams are very vocal when it comes to calling out technical obstacles in their way. The same could be said when it comes to HR related obstacles that impact Agile individuals and teams. If we listen, here’s what we would hear:

  • “Can we team interview the candidate for attitude and fit?”
  • “I was an IT Development Manager. What’s my role now?”
  • “My manager doesn’t see half of what I do for my team. How can she possibly evaluate me?”
  • “With no opportunity for promotions in sight, how can I advance my career?”
  • “Why do we recognize individuals when we’re supposed to be focused on team success?”
  • “Charlie’s not working out. Can we as the team fire him?”

As the volume increases, how will HR and HR professionals respond?

“2016 will be the year of Agile HR … most HR teams have no clue what Agile HR means”

– HR Trend Institute

The reality is that most HR teams have no clue what Agile is, never mind how it will ultimately rock their world. Most Agile initiatives emerge from the grass-roots or are driven independently by IT functions with little to no involvement from HR. HR  sits on the sidelines and watches IT “do their thing”. There is a misconception that Agile exclusively falls under the IT domain; overlooking the fact that the core of Agile is about the people and culture – the sweet spots of the HR profession.

There are three significant change movements gaining momentum:

  1. Reinventing the way we work – whether it’s IT adopting Agile or an organization becoming more nimble.
  2. Reinventing HR – where HR is moving beyond its historical focus on basic people administration, compliance and transactions to a valued place at the executive table; ensuring context and alignment across the business to generate Customer delight.
  3. Reinventing organizations – as the level of human and organizational consciousness evolves from valuing meritocracy, accountability and innovation to valuing self-management, wholeness and evolutionary purpose. (See “Reinventing Organizations” by Frederic Laloux: http://www.reinventingorganizations.com/)

All three have the common denominator of people; an integral part along the entire timeline of each movement. As these three movements overlap – at the intersection – will be HR. So, who better to help navigate the emerging paths of each change than “the People’s people”?… otherwise known as “HR”.

An analysis of the Human Resources Professionals Association’s (HRPA) Competency Framework shown below can help guide which HR competencies will have the greatest impact (on a scale of 1 to 10) on Agile.

“How do we get HR started towards their destiny?”

If you’re an Agile team member, invite HR to start a conversation about what Agile is and how they can help you and the team.

If you’re an HR professional, here are some suggestions:

  • Learn about Agile
  • Visit with your Agile teams during sprint reviews or daily scrums
  • Talk to your friends and colleagues about their Agile experiences and challenges
  • Review in-progress HR process & tool changes through an Agile lens
  • Partner with IT and other Agile implementation stakeholders to guide the success of Agile

To help HR take the first step, here are some suggested Agile learning resources:

It’s time for HR to get off the sidelines and get in the game.  HR needs to be a “friend” to Agile, not perceived as a “foe”.

Borrowing from a Chinese proverb,

When the winds of change blow, some will build walls while others build windmills… the harnessing of your greatest natural resource, your people, into power.

Build windmills.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

All you need is a bit of patience. Just be consistent in your message.

As many who have tried know, an Agile Transformation in a company is not always an easy process.  Although most people at first are keen to participate in the idea of “changing” the company culture and working environment to “something better”, many do not realize how much work it can actually be.

For some of you, you will be fortunate enough to be in an “Agile” environment already.

Perhaps you are using OpenAgile, or Scrum. You may be using a unique variation such as the Pomodoro technique.

For those of you that are new to the idea of Agile Processes, no matter what your flavor of framework or tool, there is something you will not be able to avoid.  Politics.

There is no getting around this.  Agile transformations are about change in an organization and not just change in one small section of the company.

Although many Agile teams start as “pilot projects”, even in such small situations, the effect on the departments or culture at the “edges” of even the smallest teams can start to cause ripple effects in an organization.

The first secret is to acknowledge and accept that this is going to happen.  Life will be easier for you this way. The job of any one assisting with an Agile implementation is to provide honest information and advice to help those who will be directly or indirectly impacted.

Don’t think you will be able to just hide in development and not be noticed.  Be prepared with slides, web site links, and open to talking about your processes and ideas with anyone who wants to know.  You must be transparent and open about what you are trying to accomplish.

OpenAgile for instance is defined as a “Learning System” because it deals with the realities that no one can work in a bubble and that more than just the “development team” needs to be involved in Agile practices for them to work.  The entire organization will be learning with you.

Scrum has a well defined set of guidelines to follow in regards to the development process and is ideal for new software development projects.

Lean is a more gentle approach to changing an organization in small, progressive steps.

Don’t kid yourself.  No matter how small the changes will be, there will be resistance from someone, somewhere, from where you least expected it.

The important thing to remember is what your goals are. The goal of the framework is an open and honest discussion between all those involved in your organization and general culture shift to a blameless, team based shift in thinking.

However, what is the real goal here? Happy customers, happy employees, and therefore, a profitable, progressive organization.  You must remember the purpose is not to make teams, but to make a good product for the customer. Sometimes, you may find it hard to remember.

I recently read The Wisdom of Teams: Creating the High-Performance Organization (Collins Business Essentials) by Jon R. Katzenbach and Douglas K. Smith. It clearly explains, with examples, how an organization with the courage to change their culture can really benefit from an overall culture shift towards Consultatative Decision-Making and team work based approaches.

Consistently, companies who simply “say” they have teams under-perform those that actually “just have teams”.  One type of company has them by edict or decree, and the other just has them because the culture is that way.  The ones with the naturally team based cultures do much better financially. Hmm..interesting.

Change is usually started by some kind of need to change because things aren’t working out “the old way”.

Buggy software, unhappy customers, late releases…Whatever the pain, the results are always a “desire to change”.

Those who have the courage to admit they need to change, should be applauded.  If you are new to Agile and reading this, please pat yourselves on the back for having the courage to learn more.

Now, it should be “easy” to stay on the path if you keep at it.  The act of Starting is the first big step. Congratulations!

One thing you will find as you proceed is a continual list of “it won’t work because of this”, “it won’t work because of that”.  But, hey, you’re not selling snake oil here.  You’re talking about people in an organization taking control of their work and working together for the best solution possible for the company and it’s customers.  Keep it simple.

Agile processes are just that … Processes..  They are not there to replace common sense. Agile is not a silver bullet to cure a company’s culture.  That part of things is still a human thing and will take time.  Please don’t think of Agile as a cure for a bad culture.  It is simply a way to help the culture to change.

To me at least, what is important is a consistent message.  I believe this is the key to helping an organization to be an Agile one.

Let’s take the Daily Scrum (for Scrum teams).   I worked with a company where the Daily Scrum was considered a waste of time and a nuisance for those involved (at first).

The daily scrum is a quick recap of where everyone on the team is.  For more information about the Daily Scrum, just do a quick search.  There is an abundance of information about it.  Try the Scrum Alliance for definitive information.

At this company, the owners and senior managers considered the scrum to be a nuisance. The senior developer of the team found it to be a hassle.  Then, after a few weeks of doing daily scrums, any team member could be asked by someone passing in the hall what was going on and that person could easily tell them what the status of the project was.  There are many other advantages to the scrum, but that’s not what this article is about. Maybe another time.

When I first started at this company, there was a weekly “developer meeting” which at first was the only way to exchange information.  It was generally 2 hours/week.  The team was now doing daily scrums and having small “mini-chats” (for lack of a better word) occasionally when needed.  Team members knew from the Scrums what was going on and who needed help with what and then self-organized to solve their problems and arranged “mini-chats” as needed to help each other out.

The “weekly 2 hour developer meeting” just became a thing of the past.  The team just stopped having them.

Waiting until the end of the week was far too cumbersome for something they could get from a 10 minute scrum and occasional “mini-chats”.  The team had unknowingly switched into a mode where they practiced regular consultative decision-making and regular re-assessment of their situation.

Then a remarkable thing happened.

One day, I was in a meeting, and the senior developer who at first was reluctant, banged on the window of the board room I was sitting in for me to come to the 10:00 AM Scrum which was 2 minutes away. I excused myself from the meeting and returned approx. 13 minutes later. The owner of the company said “Why do you do those daily meetings.  They are such a waste of time.  You have that big Developer Meeting every Friday”.

My response was “I’m sorry, but we don’t need to waste our time with that big 2 hour meeting every Friday anymore… We haven’t needed them for a few cycles now”.

What a remarkable experience!  In one quick step, and after considerable pain, not only was it evident that the senior developer embraced the Agile Scrum Meeting, but also the owner who was previously unsure suddenly came to realize that the team was far more effective than he knew and he hadn’t even noticed the shift.

The developer culture had changed to a more team based one without his knowing. All team members knew what was happening and Expected to be kept in the loop from now on.

The key is, keep doing it ! Be consistent.  If you’ve implemented a standard Agile practice, stick with it.

Be realistic though. There will be people who consider it to be “stupid” and there will be people who don’t want to participate.  As a new implementor, NEVER humiliate anyone in the process.  Simply encourage open discussion and ask everyone to contribute.  At first, people will be shy or nervous about this.  Over time, it will be the norm to participate.

The point is that as time passes, people and things change. The new processes will become Common Place and not so foreign and people will start to appreciate the fact their opinions are important and they have an impact on the bottom line of the company and the customer.  This is what drives people to be happy and succeed.

Then, with a bit of luck and perseverance, someone in a different department will say “Hey, I think that seems like a good idea. Tell me more”. “Do you think this Agile stuff might work in sales?” might be the kind of question you suddenly receive.  Do yourself a favor and be prepared for this with some links to a few Agile Methodologies at-hand!

This is your opportunity to introduce the new “culture” into a different part of the company.

With a bit of patience, others will come on board.  It will be a great experience for you once you have others helping out.

The day will come when someone will try and remove an Agile process somewhere in the organization and team members will lobby for their cause.  This is the day you will know…  I have succeeded with step 1… Getting started !

From here forward, it’s just a matter of consistently trying to improve things one cycle or iteration at a time, and watching things get better for the customers, employees, and of course, the stakeholders.

If I can give one last bit of advice.  Please do a bit of research before implementing something.  Ideally, you want the teams to come up with how to do their daily work, not yourself.  Let any process be the team’s process, not yours. Of course, if you have a new team to Agile, you will need to help them get started.

Consider your job as one of just guidance and coaching. That will work the best.

Review your environment carefully before deciding about methodology and do some reading or contact a coach about the differences. Should you be using Scrum, OpenAgile, XP, Lean, etc? Think about it carefully.  They have different levels of organizational change and are for different applications.  Use Wisely. :->

If you’re courageous enough and have an experienced Agile team, why not ask the team which Agile Methodology will work best for them?  I personally enjoy learning something new all the time. :->

Mike Caspar, CSM, OpenAgile Certificate Holder, ATPL
http://mike-caspar.blogspot.com

References :


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Transformation vs. Agile Adoption (being vs. doing)

Agile methods are now popular enough that the Project Management Institute has officially recognized them in a number of ways including setting up an agile project management community for PMI members.  This is a good sign, and I re-joined the PMI as a result.  However, there is still a big gap between an Agile adoption and an Agile transformation. Between doing agile methods for project management and transforming your organization to become agile in all aspects of its work.  Most people are “doing” and “adopting” agile, not doing the deep transformation.

For some years now, the premise I have been working on is that agile methods are actually all about learning.  They aren’t about product delivery.  Rather, product (or service) delivery is the context for learning.  What does this matter?

Let’s imagine two similar organizations, Abacus and Brightstart.  Both organizations want to improve the way they are working.  In fact, they both see many similar opportunities in terms of efficiency gains, productivity gains, and improvements in customer satisfaction and employee morale.  Abacus is headed up by Alex who is a visionary leader whereas Brightstart is headed up by Brit who is a hard-nosed bottom-line kinda person.  Now just to make this interesting, let’s pretend that Alex doesn’t understand Agile and just wants to use an agile method as a way to improve the delivery of projects at Abacus.  Brit, on the other hand, has some trusted advisors who have insisted that agile be treated as a fundamental transformation in the way Brightstart does business.  What happens?

Abacus

Alex gets a staff member to attend some Scrum training and launch an agile pilot project.  Stakeholder satisfaction improves because of the frequent feedback.  Some agile best practices such as timeboxing and prioritized user stories are easily adopted but others are harder.  In particular, some of the obstacles uncovered by the team are related to the corporate culture of consensus-building which Alex considers to be a non-negotiable part of the organization.  Abacus is infused with the values and personality that Alex has brought to the organization as its founder.  So when the team had trouble getting clarification on its work because the consensus-building process was taking too long, Alex simply told them to move on to less important work and come back to the other stuff when it was “ready”.

Over time, there are modest improvements in productivity and customer satisfaction at Abacus, and most of the project work is done with an agile approach using several agile “best practices”.  But any time a team encounters an obstacle related to the culture of the organization, the team loses.  Gradually, agile is treated as just another method, just another tool that may or may not be applicable to the work being done.

Brightstar

Brit researches Agile methods deeply and comes to understand that there is a process component, but also a meta-process component.  Brit decides that the potential benefit is huge: multiplying productivity, increasing morale enormously, and becoming a leader in the marketplace… but that the level of effort to get there is also large.  Agile is not a “silver bullet“.  Truly doing agile requires a deep cultural change in an organization. Brit is fully aware that changing cultures is enormously difficult.

Brit decides that all work throughout the whole organization must take on an agile culture.  This is a culture that allows for experimentation and regular reflection and learning.  As well, Brit knows that like an athlete training for a major sporting event who gets a top-notch coach, Brightstar will also need a coach.  Internally driven culture change is even more difficult and since Brightstar isn’t in deep crisis, there isn’t as much motivation for staff to fundamentally change the way they work.  A coach will help to keep the motivation, vision, and encouragement flowing so that the corporate change will be sustainable.

Brit decides that the fundamental aspects of agile that need to be put in place are the timeboxed cycles of work that include a pause for reflection, learning and planning.  All types of work can be done in that framework.  The coach is responsible for helping the organization adopt this cycle of work and keeping at it until it becomes like a perfectly regular healthy heartbeat for the whole day organization. (See “Defibrilation” below…)

Finally, Brit announces to the organization that no opportunity for learning and improvement will be denied.  Over the course of several months, this is demonstrated by several interesting incidents where staff suggestions for obstacles to be removed are acted upon quickly and decisively.  Not every suggestion results in real improvement, but all the employees quickly get the message that the environment of learning is real, and the pace of suggestions increases as does the level of individuals taking initiative to make changes directly.

Within a year, productivity at Brightstar has soared.  There is an initial bump in staff turnover as some people who were there with an “it’s just a job” attitude moved on.  After the first year, employee staff turnover rates have decreased substantially, and can mostly be attributed to changes in personal circumstances such as marriages and deaths.

Brit gets it, and is willing to be hard-nosed about learning.  Learning about product, process and people.

A Plan for Agile Transformation

I’ve worked with quite a number of organizations trying to adopt agile and trying to do agile transformations.  In that time, I’ve seen some patterns.  I would like to describe the high-level pattern of what an organization does to make a successful agile transformation.  This overall plan must not be seen as a rigorous step-by-step procedure, thus using the term “wave” instead of “step” or “phase”.  It can be visualized thus:

Agile transformation over time

Step One: Decision

The leader of the organization decides that agile is more than just another method of project management or product development, and that the vision of an agile organization is worth the effort to make a deep transformation throughout the entire organization.

Wave One: Just Start

The leader engages trainers/coaches to do the following things roughly simultaneously:

  • Introduce _everyone_ in the organization to agile concepts
  • Start _everyone_ in the organization using the agile meta-process
  • Start an Agile Transformation Team made from members of upper management to guide the overall transformation
  • Do initial cultural and process assessments to track progress over time

Wave Two: Capacity Building

The coaches and the Agile Transformation Team work with employees to develop a sufficient number of people who are capable agile facilitators.  They learn about agile methods more deeply: practices, principles, variations, techniques, and tools.  They learn to be effective facilitators who have the trust of their co-workers.  These facilitators then become responsible for ensuring that everyone else is using the agile meta-process for effective learning and simultaneously applying appropriate agile practices.

Wave Three: Sustainability

Finally, the coaches work with the Agile Transformation Team to help a relatively small number of employees to become internal coach/trainers.  These are the people who will take over from the external coaches.

As an ongoing assistance, the coaches should be working in a consultative capacity as the organization struggles with obstacles, restructuring, and the deeper culture changes.  Like any change effort, there are five critical components: sponsorship, communication, training, support and strategy.  The coaches should be advising the Agile Transformation Team and management on how these five components can best be handled for the agile transformation.

* BERTEIG Project Defibrilation:

Imagine you are doing surgery – a routine tonsillectomy on a father of two young girls. His name is Dan. Something goes wrong with the anesthesia and his heart goes nuts. The defibrillator is brought out, the paddles applied to Dan’s chest and you yell “CLEAR!”. You trigger the defibrillator, but nothing happens, just a small clicking noise. The technician quickly checks the machine, and everything looks okay. You try again. “CLEAR!” There’s a small buzzing noise and your patient’s body trembles slightly. You put the paddles down, and, getting frantic, yell at the nurses to “go find another defib machine, NOW!!!”. Thirty agonizing seconds pass. Dan’s vital signs are deteriorating. One of the nurses rushes into O.R. with a cart with another defibrillator machine on it. Everyone works like a well-oiled machine to set it up. Another fifteen seconds pass. It charges up and you apply it again to the chest of this young father. “CLEAR!” There’s a huge electrical discharge and Dan is killed instantly. It takes a few more minutes for him to be officially pronounced dead.

Is this how projects are run in your organization?

If this had been a description of a real event, you would be furious and bewildered. You would sue the hospital for buying shoddy defibrillators. You would sue the company that made them. You would demand that the defibrillators work better – one hundred percent of the time would be about right!

Let’s stop running projects this way. Traditional project management practices are like unreliable defibrillators. They work about 30% of the time. Agile is the only known reliable defibrillator for your organization’s heart.

Like a defibrillator, knowing how and when to use agile properly is still hard. That’s where we come in. We’re experts in using agile methods to fix the heart of your organization.

Contact us before your organization flatlines.

info@berteig.com
+1-800-215-2314


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail