Payton Consulting

When we first start to learn about Scrum, we learn that face to face communication is the best way for humans to communicate (as opposed to paper requirements being thrown over a wall). However, more and more clients are asking for some form of ‘Scaled out Agile’ or ‘Distributed Agile’ approach. What does this mean for ‘Pure’ Scrum as we know it?

I am not sure. What I am sure of is that increasingly we need to look beyond the walls of our own insular community for thought leadership on the areas that we increasingly find ourselves moving into: Human Performance, Organizational Change Management and Transformation, Lean Operations and Strategy.

I was talking to a client who wanted to embark upon the path to Agility, but has a massively distributed team (all in North America) and no travel budget. My gut told me to say “Sorry, no travel budget, no Agile… its’ a lot easier to teach and coach people in one place”. Yes, it is. It would have also been easy for me to walk away from a potential engagement, but just like every engagement, it was an opportunity to learn. In other words, how could I challenge the conventional thought and find some nuggets of wisdom to share from this?

We will see. I am working with a virtual team, and I myself am virtual, travelling to the client site once every 2 weeks or so.

In talking to a prospective client a few days ago, we discussed 2 projects:

1. A project that was in the ‘ideation’ phase and was looking to inject some Agility into the execution.

2. A project that was already ‘in flight’ and looked like it was doomed for failure.

The project sponsor for both projects wanted to see what opportunities there were to increase the performance of the team. The first project was a no brainer, and there was time to come in and coach the prospective Scrum Masters and Solution Owners.

The other project, on the other hand, sounded like a death march in play. The team and project manager were saying that ‘Under no circumstances do we have the time to take away from our current project plan and go toward a whole new way of execution.’ The project sponsor was thinking of putting her foot down and saying ‘THIS IS HOW WE ARE GOING TO DO THINGS, BECAUSE AGILE WILL MAKE US GO FASTER.”

I gave my project sponsor my opinion:

1. Going faster is not the object of the team understanding how to become more Agile. Learning is. When the team learns, then they will learn how to remove impediments and habits that are limiting their velocity. But attempting to steamroll ‘Agile’ down the throats of a team who is already under a critical deadline (that they most likely will not meet) won’t add any value to your situation.

2. If the team feels like they have too much to do and not enough time to do it, then that is a case of poor project discipline, completely independent of Agile vs Waterfall vs Iterative vs Predictive vs Adaptive planning. Attempting to add Scrum to the mix will only highlight that the project manager/ultimate wringable neck for the project has short changed the team’s ability to execute based on capacity, but you already know that, so I don’t see the value add. Moreover, forcing them to change something at this stage will only serve to turn the ‘change’ into a scapegoat.

I tried to make a metaphor:

The team is very good at walking, and for short periods of time, running.

I show up with a new tool called a ‘bike’ that will allow you to go further, faster, longer than you have before. Unfortunately, this tool requires learning in order for you to get the full benefit out of it. If you are in the middle of a race, where you are asked to go 500 miles in 5 days on foot, I already know that that distance in that time on foot is unrealistic, and that distance on a bike is unrealistic if you have never ridden a bike before. Even for the most advanced cyclists it would be a stretch. However, the team manager has insisted that the team needs to travel 500 miles in 5 days on foot. The team owner *knows* this is unrealistic, and is looking for a tool to help the team complete this race faster.

So me, the lowly bike trainer, is asked my opinion. Bike trainer says, “If the team is in the middle of the race that they are going to lose anyway, introducing a new tool that they don’t have the time to invest to learn how to use will only make the situation worse.” The team owner says, “but I thought bikes were supposed to make you go faster!?” I say, “yes, but only when you know how to ride it. It would not be a good idea to stop in the middle of a foot race and ask them to learn how to ride a bike, because they will blame the bike. A better option would be after the race do a lessons learned and understand what led them down the path. That type of reflection and feedback will start them on the path, and will make it easier to start learning to ride the bike.”

Anyway, sorry for the long winded meandering metaphor. I am positive others have come across this situation as well. What do you do when a panicked project sponsor calls ‘after the train has left the station’ looking for Agile to save their projects? If so, how did you handle it?

Related articles by Zemanta

• The Agile Samurai (pragprog.com)
• Agile Planning 2010 (slideshare.net)
• Unconventional tools and tecniques for project managers (slideshare.net)

Today I was having a discussion with a potential future client regarding agile coaching and large scale agile adoption.  I found out this was ‘a tale of 2 teams’.  1 manager sent 2 people to scrum training (product owner and scrum master), then decided they knew everything there was to know about agile and set off on their course.  Bravo.

Manager number 2 is the one I was having the discussions with, and manager number 2 is horrified at how things are going for manager number 1.  We had some very good discussions about training, coaching and the practical application of Agile Scrum.  They are asking if it is necessary to budget (time and materials) money for certification for key resources.

My thoughts: not up front, and here is why:  You might find yourself in the situation of Manager 1 with people looking on in horror and no-one really understanding what you are doing (yourself included).  My advice was to hire a competent coach through a full release, then evaluate how much of an accelerant (and at what point in time) formalized certification would be of help.

I have worked with some very effective Scrum Masters and Product owners who have never sat through the class, but worked with a competent coach for 6+ months.  On the other hand, I continue to hear horror stories about how organizations send an individual ‘green’ into a Scrum Master course and expect this person to be able to enact an organizational transformation.  My final word to the prospective client, “The ‘what’ behind agile is very simple and can be explained in a single slide.  The ‘how’ and the ‘application’ is very difficult and most companies who try to go it alone fail to reap the value, unfortunately.”

Organizational change, also referred to as organizational transformation, affects a corporation across the board. In contrast to smaller changes, such as reorganization within departments or hiring or firing an employee, organizational change affects larger shifts that produce a ripple effect across departments.

Examples of these changes include:

• Implementation of new technology systems
• Reorganization of corporate structure
• Change to mission of company
• Mergers and acquisitions
• Total Quality Managemen

Why Change?

Most companies, like people, are reluctant to change unless propelled by a stimulus. Economic factors, competitors, new clients, changing service needs and budget cuts are all examples of factors that stimulate the need for organizational change.

How to Make the Change Smooth

Because an organization is made up of people, and because people prefer to keep their old way of doing things, it can be difficult to get company-wide consensus on organizational change.

The key to success is to get the executive team on board, rallying behind the strategy for change. And while change is achieved through teamwork, having a change agent to communicate and envision the appropriate plan can make the change go smoothly.

And communication is key. Meeting with all levels of staff consistently to inform them on what to expect with the change, as well as to get their input, is important to maintain the team effort approach.

Change from the Inside or Outside?

While some organizational change can be done internally with existing staff, hiring an outside consultant is sometimes the best way to get a third party’s view of how the company can improve to reach its goals. Have the consultant speak to employees in all departments to get a true sense of how the company operates, and don’t just take top management’s word on it.

Related articles by Zemanta

• Organizational effectiveness (slideshare.net)
• Leadership 1.0 in the Organization 2.0 (gautamblogs.com)
• Crowdsourcing Organizational Change: A Collaborative Approach to Leading Change (vaughanmerlyn.com)

Some people who know me know that I have a background in Supply Chain and Operations consulting with a large consulting firm.  The question then is, “Why is the Supply Chain guy always yapping about Agile?”

Its because I hold a few beliefs:

1.  Even when Agile is supposed to be ‘an IT thing’, it quickly gets into larger issues of operations, strategy, and change management.  In other words, the most agile software development division in the world will be absolutely hamstrung if they are cocooned by an ‘un-Agile’ organization.  Organizational agility has a direct effect on operational effectiveness.

2.  A lot of strategic initiatives in larger organizations these days revolve around ‘becoming more lean, becoming more agile’.  So what that means is that we, from an organizational management standpoint, will need to start challenging our own assumptions about how to manage teams, divisions, and organizations.  In short, command and control wont always work.  A sound understanding of what Agility is and is not is at the heart of an organization becoming more Agile.

3.  As agile starts to move beyond the immediate circles of IT, it will very quickly need to evolve a significant change management aspect.  Change management is at the heart of any transformational strategy (such as the move to more agility)

Agile methods stress the importance of face to face human interaction (People > Processes).  Even if everyone can’t be physically co-located, moving people around helps.  It is extremely helpful to ensure that at all times someone from the US team is present in India to help facilitate the communication between your onshore team and your offshore team.  These ‘Ambassadors’ are already starting to become a very important part of any offshore-Agile efforts.

Your ambassador, assuming they are coming from the US, is already familiar with the people and personalities of the US-based team.  Bringing that personal connection will help everyone communicate more effectively.

When you send an ambassador from India to the US, the Indian ambassador gets the benefit of first-hand experience in dealing with the US-based team.  This person brings back connections and trust, which he/she shares with the rest of the Indian offshore team.

When you send an ambassador, don’t just send a developer every time.  Send some of your business-oriented people as well (business analysts, product owner, product manager). The most common model for off shoring is to have the requirements defined onshore, and send them offshore to be built.  But building software from just a list of requirements misses out on a lot of the business context – you are telling your offshore developers *what* to do without telling them *why* it’s important.  Sending a business-oriented ambassador to your offshore development team can make a big difference between doing the right *what* and the wrong *what*.

Ideally, you want to rotate your ambassadors once per month.  Ambassadors are an important part of trust building ‘across the wire.’  As a result it is important to send Ambassadors as early as possible in the project.  If a project runs for a time without ambassadors in place, miscommunications and bad feelings can develop and will take a lot of work to fix.  Ambassadors reduce this risk, but need to be in place before problems start setting in.

The costs of having ambassadors soon repay themselves in improved communication.

In my whitepaper entitled “Agile Estimating,” I talk about the importance of the business owning the prioritization of the backlog. I sum it up by saying, “If there is no prioritized backlog, there is no Agile project.”  I think this is worth repeating and worth a closer look.

When you look at the historic reasons *why* software projects fail, one of the primary classes of software project failure modes is the lack of appropriate involvement by business leadership.  This can be manifested by a lack of a backlog prioritized by business value, a lack of baselining of what constitutes high business value, or simple apathy on the part of the business.

While Agile is often sold as a ‘new IT method,’ I often say that the problem with Agile is that it doesn’t stay cleanly in IT, even though some organizations want to keep it there in a bubble, not affecting the rest of the organization.

In non-technology based Fortune 500 IT departments, I see this a lot.  An example is the industrial equipment manufacturer that has made lots of progress on the manufacturing and design side as far as rapid design and lean (demand-pull) manufacturing techniques but still uses the same predictive planning up front IT processes.

IT can and *should* be a competitive advantage for any organization and it should act as a value multiplier for the core business.  With that said, the core business needs to heavily involve itself in any IT project that will have a non-insignificant impact on operations.  ERP, CRM, PLM, and large custom-developed software all fall into this category.

One of the common problems with a lack of business ownership and commitment to a project is as follows:  An IT organization (whether it be internal or a consulting firm) is asked to implement an ERP system in order to streamline operations across the business.  There is much efficiency to be gained by having an enterprise system, but if there are no enterprise process owners of the enterprise processes that the system is implemented to support, you get a mishmash of incongruent processes and a myriad of bolted-on customizations to support the whims of various departments.  This demolishes the value proposition of the ERP system because the cost of maintain, supporting and upgrading the system becomes MORE expensive over time.

Senior leadership needs to make a visible and ongoing commitment to these types of projects.  They should be underpinned by a solid, well understood, and effectively socialized business case.  The governance structure should allow for quick decision making if there is bickering between divisions.  Last, but not least, there should be a robust organizational change management and communication strategy underlying the complete project.

The other day I was presenting a set of metrics for our sprint teams to a group of IT managers.

They asked about the burndown and what it meant in terms of scope creep.  I explained that everything the business lists as a requirement after they see working software we take down as a gap or a bug, then it is prioritized along with the other laundry list of scope items.  We have limited time and budget, so the items that are of highest business value will be delivered first, and so on.  If the business sees a gap as higher priority than one of the previously identified areas of scope, that’s fine, we take it into account and move it up the list.  That way, we are always aligned with what the business deems highest priority.

They asked about the backlog and how we could tell if a project was ‘late.’  The concept of a project being late is predicated on a predictive schedule, which we weren’t following. Since we are following an adaptive schedule, it’s not so much about late as much as it is about what won’t be delivered based on time and resources.  They were ok with that.

As I began talking about feature velocity and how we measure it, one of the managers asked, “Yea, but how can we tell how efficient our guys are?”   The answer to that question is that I consider ‘efficiency’ a false metric.  That is to say, it gives everyone the warm fuzzies to talk about ‘our developers are 99% efficient,’ but when it comes down to it, feature velocity is a much more effective measure of how well your team is doing than how much of their time is utilized.  It reminded me of the old time and motion studies they used to do to figure out how efficient someone was.  For an assembly line manufacturing environment, this might be a good indicator of factory output if you have a standard number of widgets that a worker creates in an hour.  But for software development, it might not be so good of a measure because software development ebbs and flows and has breakthroughs and backtracks.

Ultimately if we see the delta between the team’s estimates and actual decreasing and we have an increasing feature velocity sprint over sprint, that should be all the measure we need to show the process is working as designed and that the team is getting better at delivery.  In other words, if it’s a relay race with a team of 6, it’s not the team that is running 100% of the time that wins, it’s the team that masters the dynamics of teamwork and handoffs that is most effective.  The team who gets the baton across the line first wins.

Image via Wikipedia

While a Scrum Master performs many of the same duties as a Project Manager, there are some key differences.

A Project Manager oversees a project and makes sure it meets its set goals and objectives. A Project Manager’s tasks can include:

• Defining objectives and goals
• Creating project requirements
• Managing time, cost and scope of project
• Ensuring project members stay on task and on deadline

In the Agile methodologies, a Scrum Master does all of this and more. As the Product Owner of a project, the Scrum Master represents the business. He prioritizes the end results to ensure they meet the goals as well as reasonable expectations. He also works between the client and the delivery team, and creates a balance between the two entity’s goals and ability.

A Scrum Master adapts the Scrum process to a given project’s scope. He may adapt his role depending on the need and size of the team. If the team is small, he may act as a tech lead, while a larger project may have multiple Scrum Masters, each overseeing a different component.

A Scrum Master serves in the best interest of the team. While many projects suffer from unrealistinc deadlines and expectations, in Agile, a Scrum Master makes certain each team member is capable of achieving his set of tasks for a sprint. At the same time, the Scrum Master makes sure the client is aware of what should be expected, and no one is disappointed that projects go past deadline, because they rarely do.

Wikipedia defines Organizational Change Management as follows:  “Organizational Change Management aligns groups’ expectations, communicates, integrates teams and manages people training. It makes use of metrics, such as leader’s commitment, communication effectiveness, and the perceived need for change to design accurate strategies, in order to avoid change failures or solve troubled change projects.”

This is important for Agile Project Management because when we look at large enterprise projects this is most often the cause of failure.  We have a stellar project manager, we have a superstar team of developers, a highly astute group of business analysts, and a core team of wizard architects, yet the project was still seen as a failure.  Why?

Because the most talented project delivery team and the most sophisticated whizz bang technology doesn’t change the basics of human nature, and one of the basics of human nature is that people are resistant to change.  OCM is a discipline that studies change in an organization (easy, right.)

Let me state it again:  People hate change. When an engineer in 2010 looks at the DOS program that Mary has been using for the last 15 years to enter orders, then sees her print out the manifest, take it to Bob, who pulls the order from the shelf, writes the date, time and release on a piece of paper, then takes it over to Ned who gets it ready for shipping, he sees a Rube Goldberg machine that if properly digitized, optimized, and streamlined could unlock all kinds of value for an organization!  Excelsior!

Not so fast Sparky.  Mary knows how to do her job.  Bob knows how to do his job, and Ned knows how to do his job.  They have ingrained patterns of behavior that give them a certain level of comfort with the current system, warts and all.  If you come in with a customized automatic digital sign-off and order routing system, the whole order to cash ecosystem could very well come to a screeching halt.

As Agile project managers and technologists, we cannot continue to look at software development and packaged software implementations in a bubble.  We need to recognize that the cause of ‘perceived’ failure for many a project is the lack of understanding and respect for how and why people are prompted to change.

I have looked at many technology project plans and have seen no provisions for guiding the organization through the change curve.  Zero understanding or respect paid to training the users (what do you mean, I’m a UI GURU…. IT’S INTUITIVE!!!).  Try telling that to Mary when she says, “It just doesn’t work!”  What she really means is “It just doesn’t work FOR ME.  I didn’t buy into the idea,  I wasn’t prepared, I wasn’t trained and dammit I don’t like it!”

The next time you are envisioning a project, don’t just think about the developers, dbas, architects, testers, and business analysts.  Think about a communication plan (early and often).  Think about how you can get executive leadership to take a visible role in enabling change in the organization.  Think about how you can expose the organization to the project progress, goals, and value.  In short, think about your customer.