For those of us in the software development community, we observe many methods by which teams or companies define their software development life cycle. In 2001, I had the pleasure of working as a QA engineer with an eXtreme programming shop. This was the beginning of my fascination with Agile. Of course, I didn't know back then that it was related to Agile. Agile was not a term that was used. Fast-forward to my working with a company that implements the Scrum framework and uses the term Agile
. But I still didn't realize that Scrum was under the Agile umbrella until I had undergone some more self-study and continuous improvement.
The interesting thing is that when I am approached for Agile positions as a ScrumMaster (SM) or an Agile product manager, I know that the hiring managers are not really looking for someone who will be a SM for an existing team where Agile is up and running. What they're looking for is more of an experienced trainer or coach to educate and transition teams to Agile. That person has to have a proven record and experience in transitioning teams to Scrum (mainly) and will then stay on in a SM capacity.
After the hiring manager has established that the Agilist has the right background, the conversations evolve from generic SM role validation or interview to something whereby the interviewee goes into consultation mode and tries to answer the following questions.
Introduction: The coaching alliance discussion
- Why Agile? Why now?
- What is the level of experience of the hiring manager, teams, and leadership team with Agile? Who is the champion, both at the director and C-suite level?
- How much time do you have to allow Agile to kick in? (This relates to another question later.)
Current company problems
- What needs to change?
- Explain the current problems and what you hope Agile can resolve.
- How often do you release new code to production?
- What is the quality of that code? Do you find major production bugs?
- Are you working on the right things?
- Are your business stakeholders happy? What would make them happier?
Agile is not for everyone
- Is everyone on board with the transition to Agile? Do the decision makers know what it means?
- Do the functional managers understand that it might change their level of involvement with the teams and delivery?
- Will the stakeholders who dictate the work for the teams understand that the communication channel might change?
- Will the executives understand that they have to let the process happen? Do they understand that if they are micromanagers, they will cause the process to fail, especially if they keep interrupting the teams?
- Do the teams consist of the right members with the right mindset?
- Was a pulse taken to determine who was in favor?
- Do you have anyone who's resistant to change on your team? In management?
- How will your employees react to having a mentor/trainer to begin the transition? Who will be implementing the framework?
- Will management set the stage that we are transitioning to? Do they understand that the coach is here to implement it? People should make an effort to adapt to this new way so that it can succeed.
- Are there external parties that may not be under our "control" that are not using any Agile process? How involved are they collaboratively?
- Do the engineering functions employ best practices for their role that are not specific to Agile? For example, code review:
- Unit testing (development)
- Bug triage
- Validation prior to production release
- User acceptance testing
Feedback loop and expectations
Based on my experience, below are some averages the hiring manager should expect, as well as some important questions:
- Teams who use story-point estimation should expect to have an average velocity identified within three months (six sprints).
- Teams should adapt to the Scrum cadence intuitively within six months (and in less time if team members adapt well).
- Teams should be self-organizing within eight months to a year (this is based on team makeup and management support).
- The goal is to work toward a potential shippable increment in each sprint. This may not mean deployment, but all the work for that sprint is "done."
- How often would the Agile champions and the Agile coach/trainer/mentor need to speak to assess the success of the transition?
- What are the information radiators that upper management must feel comfortable with right out of the gate and going forward?
- Does everyone know that we will not be Agile in six sprints? We will be on our way, but we will not be finished.
What are you willing to accept?
Agile exposes issues (process and people); thus, a transition is usually painful. People may get upset. Those who cannot adapt will quit, while others may have to be released.
Usually at the end of this dialogue, I will have a sense of whether this company needs my help, to what extent they will need help, whether I can help them, or whether it's the right fit for me. I like a challenge, but only if I think I have the support of the people who call the shots. In my opinion, Agile cannot fix everyone's problems, nor is it a silver bullet. I firmly believe that it's the people, from top to bottom, who apply the Agile techniques that are the key to a successful transition. Without the human element, embracing the notion of doing the right thing, being part of the change, and open to transparency and commitments, Agile will be only a framework that uses a process — to no avail.