Agile Processes
When an organization starts out its processes are loosely defined. Why complicate things? When there are few parties involved, communication can remain informal. It’s usually easy to get in touch with each other. Transparency is preferred because of the close relationships held with the people involved. In many cases this is often an advantage. There are few bottlenecks from endless rounds of approvals needed, and things can be done on the fly without the need to document everything. This allows workflows to be executed quickly. However, as a company expands to bring on more complex customers, hires more people, creates more teams, and hires individuals to manage those teams; things can quickly become much more complicated. Expectations can be increased unevenly across teams.
In many cases, individual teams are allowed to manage their own development process in their own silo. Sometimes different teams can adopt their own development tools as well. This can often happen in a situation where a new team is acquired through a merger and the newly acquired team already has its own processes and tools in place. The leader of the organization might see this growing chaos and feel the need to create order. Decision makers look up the Agile Manifesto and see: “Individuals and interactions over processes and tools.” Does this mean that we are “Agile” if everyone is allowed to do whatever works for them?
One of the common misunderstandings of the Agile Manifesto is that “Agile” means “Do whatever works for you.” But if we take a closer look at the phrase “While there is value to the items on the right, we value the items on the left more.” – we can come to a similar conclusion: While it is true that we value individuals and interactions more than we value processes and tools, that does not mean that processes and tools have NO value. In fact, poorly defined processes and the wrong tools can lead to individuals having more frustrating interactions with other individuals – their teammates, vendors, and in the worst event even customers.
The way to show that management values the time of their employees is to make the process for the worker more efficient. If Team A has Jira but Team B has Trello and their work has dependencies on each other, not using a common tool can adversely affect communication and thus interactions between the individuals on those teams.
Often when problems crop up and organizations look for efficiencies, what tools each team can use for development becomes a decision that is based on cost efficiency rather than team efficiency. Many times, when deliverables become delayed and communication breaks down, the first instinct is to bring in a new tool that all the teams can use. While this can help account for some disfunction an organization may face, in many cases the software development processes that are used by disparate teams become the cause of more problems.
Even if the CIO has taken the lead to bring multiple teams on the same development platform, they haven’t accounted for the process that must be followed now that everyone shares a common platform. While there is value in bringing in a new development platform like Jira Software – this is only one half of the necessary solution. It’s important to give users training on how to use any new platform. This is a necessary consideration so that teams can use the new platform effectively. It’s also necessary to train your teams on using a common development process framework (with some allowable customization between teams). While this all sounds great, as a CIO we think to ourselves: We are already spending some budget on the new tool – implementing the new software development platform – Jira Software. How much should be budgeted for processes?
Questions to Ask When Budgeting
Who in the organization owns the software development process?
How much customization of the software development process is actually needed by different teams?
Is it due to product differences or differences in delivery expectations?
Is there a way to measure our success and efficiency across different development teams?
Do we have any experience with the Agile framework development methodologies like Scrum and Kanban?
Have we put oversight roles in place to make use of these methodologies successfully?
Do we have an individual with the right expertise (and time they can devote to it) who is able to lead an effort to standardize our processes and measuring results across teams?
Does our current company culture accept change easily?
How entrenched are old habits?
Implementing Agile Methodologies
- Empower Team Leads (or Scrum Masters) to form a Center of Excellence and own the organization’s Agile training: For this to be effective, you need very dedicated resources with the right expertise to lead the initiative. Often, it can be hard for these individuals to find enough time to work on the effort to go Agile. The Atlassian Agile Coach offers information and tips that your organization can implement.
- Budget Agile Training into your training department’s program: If your organization has training classes, this can be a way to ensure that your associates at least have a day of classroom time devoted to learning Agile. While this can be a good start for those without Agile experience, it’s important to learn continuously. Ascend Integrated offers the Jira Essentials with an Agile Mindset class which both teaches how to use Jira and how to use the Agile Framework with Jira. For more information about Agile classroom learning contact Ascend Integrated.
- Structured Agile Transformation: This would be a top down organization-wide initiative that places importance, time, and a monetary budget on developing the Agile Framework. This works best with hiring a third party agile expert with experience with multiple organizations and situations that can get measurable results without the need for an internal individual to have to devote time and effort. With a third party leading an Agile Transformation, they can also have the authority and ability to motivate others. Ascend Integrated can lead the way at your organization with Agile Coaching and Process Consulting.
- Scaled Agile for Enterprise (SAFe) Implementation: This is the most comprehensive methodology. Plan for a minimum of at least a half year (two quarters). For companies with 125 individuals or more, this can be a way to manage both individual teams and teams of teams. An outside third party leads the implementation and helps develop the organization’s individuals who will be owning the agile process in the future. Ascend Integrated is a Scaled Agile for Enterprise Bronze Partner and can enable a SAFe transformation with using the Jira Software suite or other tools at your organization.
For more information to help determine what the best path to Agility would be for your organization, contact Ascend Integrated. Ascend Integrated is a Atlassian Partner.