Choosing right agile pilot

Many students ask me how to choose a pilot? To ensure success of your transformation, it is really important to choose a right pilot. Below I will give  a few suggestions. These suggestions have worked for me in while choosing an Agile pilot.

  1. Select a “Visible but not critical project”. It is important to choose a project that has visibility across organisation. This will make the next steps of spreading agile easier. When we select a visible project, it becomes difficult for detractors to dismiss the success. At the same time be wary of selecting mission critical projects. Too much is riding over success of such a project. In this case, the team will be less likely to experiment. The stakeholders will be even less likely to have the necessary patience.
  2. Size Matters!! I usually suggest to select project which is not too large. A large project has additional scaling challenges. These become  an overhead while trying to implement agile. Usually not more than 3 scrum teams is a nice rule of thumb to follow. I also caution against selecting a too small a team. Such project may also mean a success which is not as spectacular to be tooted across organisation. A really small project delivered by a small team is anyway likely to be succeeded and agile would not get the crredit for the success!
  3. Where possible avoid added complicating factors. If at all  possible, it is better to avoid a project with unnecessary complications.Some examples can be, technology which is too strange to the team , a team that is greatly distributed (more that 3 locations)  or a team that is too new and still in “forming /storming” stage. Changing way of work to Scrum is anyway stressful, it is best to avoid further stress. 
  4. Select a project that intuitively needs agile It’s best to select a project that has need to evolve requirements – in other words it’s best to have a pilot for starting a brand new product. It will allow the inherent agile qualities to shine..At the same time, we would avoid added complications of a monolithic architecture or a legacy code base that no one fully understands.
  5. On board the champions – Identify your supporters early and include them in your pilot. These people are any way convinced and they will work hard to prove the concept.
  6. Avoid The detractors – In the same vein, it is usually prudent to avoid strong nay sayers. They usually will come on board when they see the pilot succeed. This will reduce the stress of having resistance along every step of pilot

Agile Transformation :: A Secret Sauce

We discussed sometime back that each agile transformation is completely unique. We don’t have a blueprint or a template which tells us how the ideal transformation goes. In fact there is nothing like an ideal agile transformation. You only have your own transformation.

Even then, almpst all successful agile transformations show some common elements. Transformations that I was part of also validate these elements. In  this article , I want to describe the secret sauce needed to make your transformation successful.

  1. Acceptance that current way of work is not working. For any agile transformation to succeed , the teams need to accept that our current way project execution is not working. Unless teams have really accepted this fact, they are not likely to have the motivation needed to bring about such a humongous change
  2. Willingness to adopt scrum. Scrum requires a lot of change in our current way of working. It is human nature to be wary of the change. and people are not really be ready to change their way of working so drastically. Therefore, it is not enough that the team acknowledges current way of working is not succeeding. They also need to be convinced that at scrum or agile are indeed the way to success. This conviction about success of scrum  is essential for successful scrum transformation.
  3. Agile/Scrum is not limited to IT only. I have met many business stakeholders who insist that their users cannot really adopt to this new way of working. These users are often used to having long requirement specification documents. They are now scared to work in a way where they have to give the requirements in a small vertical slices. They insist that for their organisation, it may be a better idea to become IT only agile  where the development happens in sprints after the requirements are frozen!! According to me, this is not agile but actually mockery of what agile is really supposed to be. To get real benefits that agile can offer it is important that the entire life cycle is being done in agile and not just part of the life cycle.
  4. Create the right support structure Scrum works when the team has right supportive ecosystem. Setting up this ecosystem requires the organisational structure altered to suit the scrum work way of working. This may mean adapting the contracts, legal , infrastructure ,HR policies…List is endless. The change truly is pervasive.
  5. Set the teams for success with with seeding in capability. As I have said often, agile is a difficult change. As the scrum guide says it’s easy to understand but difficult to master. Many organizations believe that they can just to send a few of their people for scrum master training. They then imagine that these newly trained scrum masters can drive the transformation on their own. This approach usually does not work.Training is definitely necessary . It helps with knowledge acquisition. But its not enough by itself. The newly trained scrum masters will usually end up with multiple issues while implementing scrum. They struggle converting their knowledge into skill. This is where a good coach can help the team. This person brings in outside perspective and also a fresh outlook.

Challenges In An Agile Transformation

Change is everywhere.” and “change is painful” are two statements that we keep on hearing again and again.Even then many companies enter the agile transformation thinking that this is going to be just a set of activities that they will do and boom!! They will be agile!!!!

Like always, the reality is quite different from what we expect.I have seen many companies struggling with agile transformation of for years together.In this article, I am going to explore why this specific change is painful. In other words, we are going to see the challenges we typically typically see in an agile transformation.

  1. Agile transformation never really ends. By Definition, an agile team is always on lookout for next thing to improve. This means, agile is a journey and not a destination. So the transformation never really ends. It makes measuring your success difficult. Also, the team is likely to loose their moral when they realize they will never be done.
  2. There are no templates available .While there is an abundance of material on Agile Scrum, agile looks different for each organisation. As a result, agile transformation is essentially unique in nature .There is no a proven path. More ever agility evolves over time . It is not really possible to plan your agile transformation right upfront. The plan is fluid and evolves as teams become agile. This creates a problem for organisations who are used to following the OCM  way of gap analysis followed by road map creation and then the road map execution.
  3. Agile is everywhere. Literally speaking, scrum is a pervasive entity. It impacts complete organisation structure as well as the operating model for projects.When any change is limited to a certain area it is possible to limit the blast radius. Agile other hand not only changes how a developer works but it also forces the team to continually learn new skills. More importantly,to be really successful ,Agile needs a complete change in mindset and a change in organisational structure . This impacts a lot more people than just the software development community of the organisation.
  4. Agile expects more Agile means paradigm shift to our way of working. Over the years we believed that principles like specialization, ironclad role segregation as well as meticulous plan based execution were the cornerstones of successful project delivery. “Process over people” was our mantra. Stringent processes and defined control points were put in to compensate for human inefficiencies and imperfections. Agile on other hand, puts the responsibility back on people who are executing the project. It expects the teams to step up. It needs the management  to trust the teams and have a mind set of supporting and not controlling. These changed mindset expectations are often the most difficult to implement.
  5. Bottom up and top down, a single direction doesn’t work . Many organisations are inherently top down or bottom up .In some organizations things get done when boss says so. On the other end of the spectrum some organisations change only when the teams want to. For Agile to succeed, neither approach is enough by itself. It will need a combination of bottom up and top down change approach for Agile to succeed.

These challenges beg the question, if it is so difficult is agile worth it? I plan to write a post soon to explore why organisations are going agile