Did we give up control too quickly?

When I  participated in SCRM Master class few years ago I was told that all the “authority and control” has to be given up in favor of Team Ownership, and that there will be no need in management involvement in the development process. I liked the concept of more team ownership and less management control , and I still think it makes sense. However, from observing and coaching multiple teams over the last 18 months I do not think this is a slam dunk. There are several factors that have to be considered:

1.       Team members seniority (experience, technical and product domain knowledge)
2.       Complexity of the project
3.       Novelty of the project (an incremental feature vs. new technology)

What I have found was with lower team seniority, higher project complexity and higher project novelty, the “team ownership with less management involvement” model can break.

Here are some of the consequences of operating in such environment:

1.       Missed design reviews leading to missed functional and non-functional requirements, as well as sub-optimal technical implementations.
2.       Less communication between the team members and the PO, leading to disconnects between them
3.       Misunderstanding of Agile practices and ideas, leading to something that looks like SCRUM from outside but in reality is worse than Waterfall.

It’s true that in the world before Agile we had many problems, but it’s also true that we had some good practices including certain oversight by senior team members and development managers who would help the team to ask the right questions and would enforce some of the practices such as design reviews.

In my opinion each situation should be assessed on a case-by-case basis and certain combinations of projects and teams may need to have a development manager involved during the development cycle, to help compensate for lower seniority of the team and higher complexity of the projects. If the Scrum Master for these teams happen to be a development manager then the risk is mitigated.

Executive Commitment

“Is Commitment a direction to be pursued as long as it works for you or a direction to be pursued until it works for you?” –Anonymous

Getting executive commitment is crucial for Agile transformation success. The process is long and road mines will await you surely. It will be of utmost importance to have the executive team still supporting the initiative when things get tough and the pressure to get product out increases.

I have found that it’s not hard to “sell” Agile to the executive team: what is there not to like? The value proposition of Agile sells itself and all CEO hears from others outside the company is “you have to go Agile”. So on the face of it everything looks good and executive team is all in agreement that Agile is the way to go.

When I presented Agile to execs few months ago I took a different approach. Well, I had to do the selling part, not without it, but most important I have described all the challenges and obstacles we anticipate having in our way to become Agile:

1. Shared resources (PO/UxD/Architects),
2. PO availability to the team (considering other responsibilities of Product Manager)
3. Leading virtual teams
4. Too often/uncontrolled changes in direction
5. Inability to decide on priorities in timely fashion
…and the list goes on

One thing Agile does quickly and without a facelift is exposing existing problems in the organization, and when a company embarks on Agile transformation path these problems have to be dealt with, breaking status quo and being painful to resolve at times. For example, if the company has a problem on deciding on priorities prior to Agile, the problem will not be resolved just by going Agile. Agile will show the way if you will, but the company will have to address the issue immediately.

Although I still got a green light from execs, the real test of executive commitment will be when the push comes to shove.

Hiring a coach

Agile coaching is a hot topic now – great opportunity for anyone who is in software or management consulting business to capitalize on on this new “trend”. How do you choose a coach that is right for you? To answer this question let’s focus on what we are trying to achieve. We need a coach to accompany our Agile transformation because we do not have enough expertise in-house – sounds like a good reason to hire a consultant. Our initial thought was to find a coach who has “done it” with companies of our size and with similar transformation context. We were focusing on challenges this coach had with other teams and whether he/she was successful to address these challenges, and how creative he/she was in addressing them. Here are some good questions to ask the candidate:

1. How would you address the limited shared resources situation, knowing that company cannot hire additional personnel? Specifically, how would you suggest dealing with 1 UX Designer serving simultaneously 3-4 teams? How about Product Owner serving 2-3 teams?
2. Pure SCRUM promotes approach of evolving architecture, while focusing on juiciest features. This is one area where we will not follow the guideline and would take RUP based approach, investing in architecture in the beginning. How would you approach this kind of projects, knowing this constraint?
3. Would you engage offshore team in pilot projects? If yes, would you try to co-locate or to mix teams (current model is mixed/extended teams)?

Like with hiring any senior resource it’s important to look for behavioral patterns through thought process exposed while answering the questions.
Another important aspect that we felt was necessary is coach background. It’s definitely an advantage when the coach is coming from development background experienced in both Waterfall and Agile environments. This is because there will be a higher chance to ”click” with engineers on fresh Agile teams.