Preventing Epic Failures in Agile Transformation

Preventing Epic Failures In Your

Agile Transformation

CULTURE AND ORGANIZATIONAL

REQUIREMENTS FOR SUCCESS

March 26, 2014

2 ©Alliance Global Services 2014

About Alliance Alliance is a software development and testing firm that partners with software, technology and information-intensive businesses on their mission critical work. Leveraging agile practices, Alliance architects and builds software applications, platforms and products that become primary drivers of innovation and revenue growth for its clients and their businesses. Alliance is recognized for driving quality and speed-to-market when business success depends on the software inside. Founded in 1994, Alliance is headquartered in suburban Philadelphia in Conshohocken, PA.

Today’s Speaker

As Vice President of Consulting Services in the West Region at Alliance

Global Services, Lauren Feehrer is committed to driving a culture

focused on exceeding customer’s expectations. A certified ScrumMaster,

Lauren has a passion for driving successful product development efforts

utilizing Agile. She has deep expertise in leading JumpStart initiatives

and coaching distributed Agile teams. Lauren has a track record of

running high performance software development, testing, and support

teams with prior roles within Alliance as a Regional Vice President, PMO

Director, and Engagement Manager. Lauren holds a BA from the

University of Rhode Island in Communication Studies, Journalism, and

Leadership.


AGENDA


Agenda

Why is Culture so Important?

Agile Values

Organizational Buy-In and Preparing for Change

Cultural Conflict and Tips for Collaboration

People Challenges

Role Shifts in Agile

Q&A


Keys to this Presentation

• Information Icon: More information can be found

through this resource

• Light Bulb Icon: Idea or practical implementation

suggestion here

“I cannot teach anybody anything. I can only make them think.” - Socrates

“Education is the kindling of a flame, not the filling of a vessel.”


WHY IS CULTURE SO IMPORTANT?


It’s Just a Methodology…NOT!

Agile is a CULTURE

SCRUM, XP, Kanban, etc. are Frameworks for Agile application. It contains base components and foundational guidelines. They are time-tested and altering them will impact the level of success you will achieve.

The TEAM needs to evolve in their own way of how apply it organizationally. If people don’t work as a team, don’t understand the rules, or have any other flaw in their capabilities, it shows.

• “Organization values, visions, norms, working language, systems, symbols, beliefs, and habits.

• Collective behaviors and assumptions that are taught to new organizational members as a way of perceiving, and even thinking and feeling.

• Affects the way people and groups interact with each other, with clients, and with stakeholders."

“Coming together is a beginning. Keeping together is progress. Working together is success.” - Henry Ford


Embracing Agile….Holistically

Practices, Tools Ability to manage changing priorities

Improve Visibility

Increase Productivity

Improve Quality

Reduce Risk

“Doing Agile”

Agile Mindset Customer Delight

Joy at Work

Engagement

Innovation, Creativity

Continuous Learning

Hyper Productivity

Business Value Driven

Organizational Alignment

“Being Agile”


Embracing Agile….Holistically

Cultural

Strategic

Transactional

Agile

• Who do we want to be? • Organizational Identity • Vision • Values – Integrity, Creativity,

Safe to fail, Kindness

• What do we want to achieve? • Customer Focus • Organization structure to

support the goal • Long Term Thinking • Baked In Quality

• How do we work? What is our process?

• What tools do we use? • How do we do continuous

integration? • Communication Practices

(daily scrum, other ceremonies)

Be the change you want to see in the world – Mahatma Gandhi


AGILE VALUES


Agile Values

Respect

Courage

Openness

Focus

Communication

…motherhood and apple pie, right? But what do these actually mean?!


• Define these as a group • Publicize the values and their definitions in a visible way • Hold each other accountable

Agile Values

Commitment Focus

Openness Respect Courage


How to Facilitate the Values Discussion

Suggestion:

• Ask the team:

• Think of a time in your previous project without this value (commitment, openness, trust, courage, respect)? What was the impact?

• Try to have discussion on all five words.

• Then write each of the five values on big posters.

• Have everyone write down their definition, then share it with the group, and post to the board.

• Don’t skip the paper.

• Don’t ask the senior team member first. New/Junior person should start.


ORGANIZATIONAL BUY-IN AND PREPARING

FOR CHANGE


Agile Transition – What Does it Take?

1. Teach everyone to play the game of product development

using a new framework.

– How to work together in small teams (usually 6-12 months)

2. Everyone in the enterprise improves the game so that they are

the best possible enterprise of teams working together (3-5

years)

And this is an ongoing endeavor…

• The paradigm embraces change, unpredictability and complexity as

inescapable constraints in all product development.

• Detailed long-term predictive plans = meaningless, waste of $$$

• Agile will expose flaws more transparently than ever before


FAILURE

“We are all failures- at least the best of us are.” ― J.M. Barrie

Train wreck at Montparnasse, France


Agile Transition – Prove It’s Worth It

The rollout effort is tremendous.

Before you attempt enterprise-wide adoption, you must believe

that your enterprise has problems to fix and establish buy-in on

this new framework.

Step 1:

• Use the framework on several projects.

– Get people trained (www.scrumalliance.org).

– Select high value, high risk work

– Conduct at least 3 sprints

Now… Select a Problem Project

– Identify important functionality to create the product backlog

– Have the Scrum Team iterate several times

– Extrapolate the cost of the third sprint to get an idea of an estimate for

the whole project

http://www.scrumalliance.org/


What to Expect When You’re Agile Transitioning

Attrition

“Storming Period” (generally anywhere in months 3-9)

Conflict

Product Manager Panic

Engineering Quality Improvement (increased responsibility)

Role changes

The Enterprise and Scrum, by Ken Schwaber


CULTURAL CHALLENGES AND TIPS FOR

COLLABORATION


Creating a High Performance Team

Steve Denning from the Radical Management Book Club suggests we:

Think back to a time when you had a really good experience in working with other people in getting some done. Ever had that?

Most of us can recall at least one experience…

Most everyone knows what a High Performance Team is, because they have experienced it for themselves.

And most people are disgruntled in their current job. WHY?!

“We don’t know how to recreate that experience.”

http://www.scrumalliance.org/community/spotlight/steve-denning


Creating a High Performance Team

Self Organized

Have full responsibility

The team works together

The team is focused on completing the task

The goals must be inspiring and real


Self Organization in HPTs

“Self-organizing teams are out of control.”

“As a manager, I sleep better knowing there are controls in place.”

“I just like being in charge and giving orders.”


Good Practices in Collaboration H

ere’

s w

hat

wo

rks…

Share the business impact and the value the team is providing – meetings between the ‘business’ and ‘IT’ should merge and executives presence should be there in Demos

Team building, trust, and frequent ‘retrospectives’

Recognition coming from outside the team should be given to the whole team, not individuals

However, within the team, awards can be given between peers


Advocating for an Open Space Environment



• A physical work area with a defined boundary, dedicated to a

team

– Work space design must facilitate ad hoc collaboration

• Visual line of site among the team members

• Open meeting areas

• Whiteboards

– Within the defined boundary, also have spaces for privacy, such as 1 or

2 private offices (phone enclaves) or meeting rooms

– Visual elements that make it a desirable place to be

– Reconfigurable desks



When Steve Jobs revolutionized the Pixar

offices by bringing

people with

radically different ideas and

problem solving techniques

together.

From the animators, to the writers to the

artists… they all worked in

one giant cavernous room.



• But… it’s too loud! How does anyone get anything done in that

environment??? And what about the introverts?

• Before you transform your office… watch this:

Susan Cain’s TED Talk:

• Serendipitous exchange of ideas

• Not GROUPTHINK

• Allow for privacy, self reflection

and introversion

http://www.ted.com/talks/susan_cain_the_power_of_introverts



Barbara T. Armstrong is a nationally recognized designer specializing in strategically integrating workplace design and culture.

In a Forbes article, she asks the question:

• How can the need for collaboration and the need for privacy—be realized in a single design solution?

One word: choice.

• Choice can be demonstrated in both the physical and cultural aspects of an organization’s work environment.

• Having ample space for contemplation, collaboration, and casual collisions presents workers with critical choices.

• In other words, the physical workplace that offers many diverse settings for a variety of work needs.

Image from IdeaPaint

http://www.forbes.com/sites/barbaraarmstrong/2012/05/24/balancing-the-needs-for-collaboration-and-privacy-a-tall-order-in-workplace-design


PEOPLE CHALLENGES

http://www.google.com/url?sa=i&source=images&cd=&cad=rja&docid=DOU4n6bctKwnCM&tbnid=qioZAvbnp6TjaM:&ved=0CAUQjRw&url=http://think-quick.com.au/2010/11&ei=nLU_Uaa4DMHhrAHeh4CACg&psig=AFQjCNGHYAvHmmPukGbxlgwnhz32s7qdhQ&ust=1363216089273007


People Challenges •Is the team trained in Agile?

•Is there awareness of what problems Agile is supposed to fix?

•Is there consistency in the message?

Poor awareness of Agile approach, techniques and adaptation concept

•Does an executive champion(s) exist?

•Does the leadership team participate in Demos?

Lack of leadership /

executive buy-in

•Waterfall Tyranny

•Command and Control culture Moving from Predictive to

an Adaptive culture

•Can people be added?

•How many people are on each Scrum Team?

•Turnover can demoralize the other team members and cause productivity issues Chronically understaffed

•Can the stories be postponed to a later sprint while the skill is acquired?

•Are you recruiting for an Agile team? Missing required skills

•Do Product Owners have the authority to make the call?

•Have you discussed tradeoffs? Competing priorities


People Challenges

• What teambuilding has been done?

• Are the goals real and attainable?

• Is the ScrumMaster shielding the team adequately?

• Have you focused on developing team capabilities?

Low team morale

• Do the team members treat each other as peers?

• Does the Sr. Developer(s) / Architect have an ego complex?

• Has there typically been an atmosphere of “Dev vs. QA” in the organization?

Lack of respect

• Has the team been ‘punished’ for failure?

• Have the team members let each other down?

• Has the ScrumMaster acted in a Command and Control mode?

Loss of trust

• Are there competing priorities?

• Do the teams not see the bigger picture?

• Are the teams tied up in bureaucracy?

Poor support from external teams


How do you Prevent Product Owner Failure?

• Does the sponsor have multiple customer to satisfy? (dilemma)

• Does the sponsor not have the level of involvement needed? (time)

• Does the sponsor need more research? (lack of info)

• Does the sponsor care? (engagement)

Can’t get sponsor to make decisions

• Is this a Product Owner in name only (and really a Business Analyst)?

• Does this person have organizational clout?

Not qualified to take

ownership / not respected

• Can the product owner role be split with other people?

• Can the projects be prioritized so not everything happens all at once?

• Does the product owner need to be involved in every team activity?

Spread too thin across projects/teams

• Can the stories be postponed to a later sprint while the skill is acquired?

• Are you recruiting for an Agile team? Not part of the team

• Is the PO actively participating in the Sprint Planning?

• Does the PO take full ownership of the Product Backlog?

• Is the PO actively participating in the Sprint Demo?

• Is the PO aware of the burndown?

Not playing the role effectively


ROLE SHIFTS


Role Shifts: Product Manager / Owner

Who is this person?

Previously was a ‘part of the business’… now is a member of the team.

What do they do?

• Responsible for product vision

• Must define the product backlog, prioritize it, and connect the product vision to the development stories

• Must define acceptance criteria

What’s important to know about this role?

• Decision maker – not a business analyst

• Not an order taker! This person decides the direction for the product and defines functionality.

• While on a daily basis this person may be getting feedback from customers, other departments, a large part of his/her job should be sitting in the team daily and participating in all “Scrum Ceremonies”.


Role Shifts: Project Manager to ScrumMaster

Who is this person (in a traditional envt.)?

• Previously - a Project Manager – responsible for managing scope, budget, timelines, resources, quality; “accountable neck to choke”

• Another option is to have rotating ScrumMasters and everyone play this role at different times

What do they do?

• Serve the team – as a remover of impediments, facilitator and coach

• Shields team from stakeholders, overbearing product owners, other managers, themselves.

• Facilitates openness and building trust among all team members


• Skillset: Integrity, trustworthiness, and a track record for caring about those whom they lead

• Needs to know organizational politics, and how to get stuff fast


Role Shifts: Project Manager to ScrumMaster

Servant Leadership, Robert Greenleaf

The Servant as Leader, essay first published in 1970

• Focuses primarily on the growth and well-being of people and the

communities to which they belong.

• Traditional leadership generally involves the accumulation and exercise of

power by one at the “top of the pyramid,” servant leadership is different.

• The servant-leader shares power, puts the needs of others first and helps

people develop and perform as highly as possible.

http://www.greenleaf.org/




Role Shifts: Developer


• Developer – usually sitting in own cubicle, taking assignments from a project manager. May not have ever met the “business” as requirements come in long documents.

What do they do?

• Responsible for: • Sizing stories, Identifying sprint story tasks, Estimating task effort

• Creating a quality product

• Communicating progress and impediments

• And making commitments

• Self organizing

• Must determine their own quality standards

• Peer programming


• In the Agile world, it’s much better to have specialized generalists: shift to the goal being much greater than completing the tasks

• Developers need to have the ability to turn the ‘technical’ requirement into business terms for the Product Owner/business people. Articulation is key.

• Note: there are some times where you will be ‘shared team members’ – be careful with this; have a core team


Role Shifts: Tester


• Test: examine requirements, create test cases, execute test cases, log defects

What do they do?

• Start improving the quality along with the developers very early

• Think of how to make it right the first time

• Sit at developers machine to test – even if it’s not complete

• Share the test cases with the team

• Story clarification; understanding the requirements


• Everyone has a builder mindset

• Verification is very important. But it doesn’t increase the quality. In Agile, the focus of a test engineer alters to be about how QA skills/knowledge can make the team more effective


Summary

• Agile is a Culture

• Doing Agile and Being Agile produce a very different set of results

• Embracing the values of Agile require open discussion at a team level

• Organizational buy-in requires time for piloting, and an environment that makes it safe to fail

• Transition can be met with challenges including turnover, a storming period, and conflict

• Creating a high performance team means “allowing” for self-organization

• Physical environment is important

• Working thru the ‘people challenges’ is critical

• Roles will change

…we look forward to ongoing conversations on this topic and are available to help with your Agile transition and transformation efforts!


References

Susan Cain’s TED Talk on Introversion:


Forbes Article by Barbara Armstrong:


Gallup Study: http://media2.kjrh.com/html/pdfs/unhappyemployees_gallup.pdf

http://www.mountaingoatsoftware.com/articles/how-to-fail-with-agile

Book: The Enterprise and Scrum, by Ken Schwaber

Essay: The Servant as Leader, Robert Greenleaf

Video: I want to run an agile project:

http://www.youtube.com/watch?v=4u5N00ApR_k

IdeaPaint website (whiteboard paint for anywhere!): http://www.ideapaint.com































http://media2.kjrh.com/html/pdfs/unhappyemployees_gallup.pdf

http://media2.kjrh.com/html/pdfs/unhappyemployees_gallup.pdf












http://www.ideapaint.com/

http://www.ideapaint.com/


Q&A


Q&A Question Lauren’s Response

How long does it take to go through this transition in a medium sized company?

It depends. What I’ve seen is that the beginning of the pilot which includes starting a few projects and doing an initial rollout will take anywhere from 6-12 months. Adapting to Agile (going from Doing Agile to Being Agile) will takethe next couple years after this – and there will be speed bumps along the way. It’s important throughout the process to focus on these values, and training, training, training!

How can you help Senior Engineers who have never done estimations or picked their own work before to trust the system?

Get yourself a copy of Agile Estimation and Planning by Mike Cohn – I think it’s the best resource out there on this topic. Other than that – here’s a few tips: 1) Make sure Engineers understand that an estimation is a

knowledgeable guess, and there are uncertainty factors at play. You have to have an environment where estimates don’t become promises – otherwise you make everyone fearful about what an estimate really is. Expect variation in the estimates (19% is typical).

2) Train on sizing with Story Points rather than hours 3) Do SIZING rather than estimating – use t-shirt sizing or Fibonacci – the

paradigm shift can really help as it’s more comparative in nature. 4) Talk thru the facts of the estimate. What anchors and engines are

there that may speed up the effort or slow it down? 5) Understand the definition of done. 6) Look at velocity and retrospect on it. 7) And most importantly – do estimating as a TEAM! Planning poker

works very well for this.



The agile values are very much core human values. How you suggest recruiting people with those values? How you enforce those values in a diverse team?

From a recruiting perspective, make sure you are not just focusing on technical skills. Look at the “soft skills” too. Add an element of behavioral interviewing to your process (tell me about a time when…” type questions and ask for details). At Alliance, we have multiple people participate in our interview process. The feedback from the first interview will be passed to the second interview – and it’s critical that we note: I have a concern about this person’s leadership style in this particular area – the second interviewer picks up where that concern left off to see if they can find additional information to support that concern. Make sure there are questions that focus on the Agile values. As far as ‘enforcing’ on a team… I really don’t like that word if it is management coming in to force compliance. That isn’t the idea of Agile as well. It’s up to the self managed team to enforce these with each other – and that’s why it’s so important to have the transparent conversation about values, display them, and retrospect on them frequently.

How do we measure our success/failure so that we can use that as a feedback for the future adoption planning?

Measurement / metrics is certainly important. At Alliance, we really focus on metrics to demonstrate value – in terms of both quality and productivity. It’s tremendously important to look at what metrics you have in place and what story they are able to tell. If they don’t answer key questions for you, throw them out. Always question the value. I’d recommend looking at burndown and velocity as your real measures – make sure they are calculated correctly and the team is disciplined on task tracking in order to tell the real story. Also look at customer satisfaction levels and employment satisfaction – I think of those as the most important measures of Agile success. An important point to highlight – do NOT try to introduce these on day 1. Wait until the pilot has momentum and you have some wins under your belt.



How does Agile work with a virtual team?

That’s a big topic and we look forward on providing a webinar to go into detail about how Alliance makes distributed Agile successful. At a high level, we follow all the same principles I mentioned today. What’s critical with the team not all in one locations is to do everything you can to encourage relationship building and transparency. It’s hard to have the conversations about Agile values not in the same room – but get on videoconference (Skype makes that a lot easier!) and travel when possible. Also make sure you have tools that allow for visibility and tracking. We’re big proponents of JIRA at Alliance – but there are plenty of other tools out there that help. Think about the things that you’d have in place if you were in one office together – then see how you can recreate that virtually.. And how you can humanize it as much as possible.

Recently our scrum master cancelled the retrospective meeting is that a bad sign?

Was that a team decision, or his/her decision? Why? I look at that with curiosity, but my gut would tell me that something is going wrong. What was the reason for the cancellation? If the reason is that there is no value in the meeting, no one was speaking up, it became a complaint session… then the meeting needs to go through some changes. Perhaps putting some structure into it would be helpful – suggest discussion topics like: Estimation, Product Owner involvement, Stand Up Meetings, Demo, Collaboration, Burndown tracking, or whatever else your team focuses a lot on. Hope that helps!



Do you have any insight into how to implement scrum in a professional services company?

Absolutely – we’d love to discuss with you further to understand what unique requirements you may have. The fundamentals of Agile can be applied to any environment, and Scrum is a fantastic framework to use! I just watched a TED Talk last week on applying Scrum to our families: http://www.ted.com/talks/bruce_feiler_agile_programming_for_your_family I would assume some of the adjustments you may need to make, since you may not be ‘building product’ is to think thru how a Product Owner role would work. Questions to think about: Who defines the user stories in the environment? Whatever you are developing, can your team work together to break it down into small tasks? Do you have something to demonstrate at the end of a Sprint?

How does Agile work in a small environment with a group that wears many hats (requirements gathering, programming, testing, etc...)?

Agile (the Scrum framework, in particular) works best when done in teams of 5-9, and the most successful folks are those that can wear a lot of hats. The ‘team’ concept has less defined roles than in traditional development. If you have particular challenges you would like to discuss, please feel free to be in touch - we’d love to see how we can help!

http://www.ted.com/talks/bruce_feiler_agile_programming_for_your_family


Thank You Lauren Feehrer

Vice President of Consulting Services, West Region

[email protected]

www.allianceglobalservices.com

mailto:[email protected]

Date post:	06-May-2015
Category:	Technology
Upload:	alliance-global-services
View:	335 times
Download:	3 times

Preventing Epic Failures in Agile Transformation

Technology