In this series of dispatches from the field, I analyze how you can better innovative and adopt Agile and DevOps ways of working – to drastically improve development speed, quality, innovation, and business agility.
It’s people, people, people …
In my previous dispatch, we looked at some of the key questions you need to answer before you start your journey to Agile at Scale. The hard questions are all centered around changing people’s behaviors and expectations. It’s a given that, in general, people don’t like change. In fact, they will probably fight change – even when they know it’s good for them. People like to feel comfortable and will focus first on tangible things to provide them with the comfort and control they intuitively seek. This comfort and control usually manifest themselves in the selection of tools.
One of the most common mistakes here is a rigid focus on tools. For example, Rally, JIRA, and VersionOne are great tools and can help teams collaborate – especially with distributed teams. The problem is that they can drive bad behavior and constrict collaboration. It starts with the way that they are presented to the community. Don’t forget that people are comfortable with mapping their old behaviors onto a tool. The old behaviors were all based on the notion that somebody writes something down and then hands it off to somebody to build. This breaks the first key value of the Agile Manifesto – “Individuals and Interactions over Process and Tools.”
Instead of collaborative workshops with the users and development team creating the stories together and gaining understanding, we see people loading “stories” into the tool for developers to “work.” Even worse behavior is when the backlog consists of “tickets” to be worked that are input into the tool. Again, no collaboration – just task management against written requirements. If you can’t get past this limitation, you cannot scale – let alone call your organization Agile. Change the way you work by scheduling Backlog Refinement sessions to capture, estimate, and prioritize work. It’s a team effort and not an exercise in data entry!
Training change, training people
The next common pitfall I encounter is the introduction of a process as a training exercise without an understanding of the change involved. The number-one failure in all Agile transformations is a lack of change management. I like the ADKAR model from Prosci that combines both business and people dimensions. It has five steps to enable change on the people side. The elements of the ADKAR Model are:
- Awareness of the need for change
- Desire to participate in and support the change
- Knowledge of how to change
- Ability to implement the change on a day-to-day basis
- Reinforcement to keep the change in place.
In order for the process to work, you must embrace all of the above. Without proper attention, people will revert to the old ways of doing things.
Are you credible?
People won’t follow you if they don’t believe you. Nothing happens if people don’t change or deal with bad behaviors. Credibility is built through actions and not with just another PowerPoint presentation. If people don’t believe you, they won’t try – or even sabotage what you are trying to accomplish. Start slow and build credibility first – honesty and approachability are key here.
Admitting you were wrong!
Taking credit for all the wonderful things we do is easy – but admitting something wrong is hard. You need to look at how you have adopted Agile and DevOps in your organization and assess your process on a regular basis. Poor common practices called “anti-patterns” can discount the process and increase risk.
It’s amazing how many embrace these so-called “anti-patterns and use terms like Hybrid, Wagile, ScrumBanWIPDevOps, or “Our Way.” In many instances, the organization has been given the wrong direction and training in the process. A person that just took a two-day scrum class should not be coaching your organization.
So, you think you’re ready?
Ok, you think you have most obstacles identified and an action plan to fix them. Now is the time to ask yourself – what is it that you really want to accomplish with scaling your teams?
- Do you want to focus on product development or large multiple value streams?
- Do you want to reduce chaos and align with business objectives, etc.?
- Which scaling framework should you choose?
Contact me here and we can discuss these questions in more detail and lay a solid foundation for scaling effectively. In my final dispatch in this series, we’ll look at how you can really take your scaling efforts to the next level and mature your entire organization with Capgemini’s ADMnext.