You've spent the last months or years developing Agile methods for your team, driving the people and the management toward understanding, acceptance, and finally the sponsorship of Scrum or any other framework that has proved to be suitable for your situation. Now the time has arrived to start over again in a new organization. Or perhaps you have been placed in this role for the company in which you are already working as a consultant, manager, or developer.
Welcome to your new world! But now . . . what do you do?
I'm not going to provide you with the instructions, but I propose a set of tools and attitudes that -- in my experience -- can be useful.
As an Agile coach or Agile leader, your role is to "direct" a group of professionals toward a better way of working. (Please keep this in mind: This is also a fairly important mission of the Scrum Alliance!)
If you have not changed companies but you've recently been chosen for this new position, the first exploratory phase may sound easier than other phases, but it still presents several risks. You need to strip yourself of any prejudices about people or processes that you have developed over time. In addition, and more important, you have to remap your role and explain what people should expect from you. Avoid finding yourself embroiled in dynamics inherited from your previous role that could threaten the focus of your new assignment. Were you a project manager? Categorically reject any management activities: workloads and planning. Were you a developer? Uninstall IDEs, change the passwords to the development environment. In short, free yourself from the possibility of having to say "Fine, I'll do it myself." Stay focused.
If you're "the new guy" in the company, seek to clarify from the start how you can contribute to the group and what activities (see below) you'll have to work on in the near future. If your mandate is supported by management, this will not take much effort. Otherwise you will need to repeat it several times, reminding them that you are there to make them work more efficiently. You are not a problem solver, or a new manager, or even a new boss who will be supervising them.
Understand the "why"
As a first step, you need to understand the reasons why the team and the organization have embraced the idea of change. Is there too much confusion? Are products not released on time? Do the products have too many flaws? Are people unable to sleep at night from all the worry? Is nothing working?
Very often, these are only the effects of a series of technical and organizational dysfunctions. This is why you need to go in depth. Try to force some typical Agile technique or event in order to gather "very" important information, and in the meantime introduce the values and foundations of the method. For example, assume that the work week corresponds to a "sprint" -- regardless of how many products or releases are handled -- and bring in a sort of daily Scrum for at least a week. See what happens. Look at the impact of having a meeting in the daily routine, as well as the different attitudes and the recurring themes.
Look back . . . to go forward
And why not start with a retrospective? Together the team will need to choose a product, not the most important or the most marginal but a middle ground. Conduct a retrospective, choosing among the various techniques that can facilitate discussions on process and satisfaction. No matter what stage the production or release is in, draw a line and get a picture of the situation. Collect as many variables as possible.
Among the various techniques for performing a retrospective, in order to obtain a wider view of the situation, a "timeline retrospective" is effective. Involve as many people as possible: developers, systems analysts, sales developers, managers, and designers. Draw a horizontal line on the board and propose this exercise: the product
(or the "sprint") of which you're going to perform the retrospective are the last six months of work
that the company or team has done. Make them write and stick post-it notes on the timeline in different colors:
Green: positive events
Yellow: events for which a different outcome was expected
Orange: negative events
Try to facilitate the activity by suggesting something you already know about the portfolio or the technologies used, but keep the investigation focused on the events and a true representation of the satisfaction of the people involved. At the end of the activity, you can identify patterns or specifications that will guide the focus of your business in the next period: thorough investigation, evaluation of solutions, adoption, and measurement.
The next step is to know whom and what you are dealing with. There are several ways to conduct an Agile assessment within one or more teams. You can find several tips online about how to conduct an assessment. The important thing is to quickly get a complete map of people, skills, technologies used, the physical layout of the team, schedules, and current production processes. The goal is to roughly understand the size of the mountain that stands before you.
Is the code shared, versioned, and tested?
Are the development and production environments well organized?
What kind of documentation is produced and maintained in a "normal" project?
Which figures are involved in the various stages of the production process?
And so on.
Mind you, the need to perform this exploratory phase is clear: You have to start somewhere. However, it is the way in which you conduct these activities that will be advantageous, rather than the amount of "technical" information gathered.
Talk. With everyone.
During the assessment phase, do not settle for talking with managers, leaders, or spokespersons. Nor with owners or the CEO. Speak with the team. Organize short but frequent meetings with working groups and with each team member, to deepen skills and points of view. Use this time to point out your role and the purpose of these talks: Identify the weak spots in the process
and the strengths of the people
Create a transparent and honest relationship with the people with whom you need to work, try to smooth out any preexisting conflicts, and build a bridge to the past using the results of the retrospective analysis above as a starting point.
Make your work visible
Do not confuse your role with that of a human resources manager. Do not allow your meetings with your colleagues to become a place where they can vent about what works or doesn't work, on how things should go, how much they are paid, and so on. Focus on the facts, on what is actual and measurable. It is usually what works and what doesn't work.
Immediately start and continue to use "we," never "you."
Make the outcome of the assessment and its evolution visible, create a board where you can show a "General Impediment Backlog," the "Corporate Overhead Estimation," and any other important indicators of the material that you are collecting. Making the information visible is the best way to make everyone participate without interrupting them or having to arrange further meetings.
Full speed ahead!
What are the next steps? It's obvious: It depends. On the people, on the information, on the past and present of the organization. You may begin to work in Scrum for a pilot project and with a dedicated team, or organize general training sessions on the principles of Agile and Scrum. You may find that motivation is not well distributed between developers, managers, and directors, and you will therefore need to work on several fronts with different attitudes.
The goals that you strive for, in the short term, are as follows:
To be accepted and recognized as a facilitator and "servant leader"
To write the first drafts of a "working agreement" and a "team vision"
To find the contact points (or the conflicts that must be resolved) between business goals and those of the team
To identify the most effective tools to communicate and share values within the organization (board, canvas, maps, etc.)
Finally, do not forget: You have to map the route of your new Agile adventure, with new people and new challenges.