Congratulations, your organization has made the decision to embark on transforming your product delivery to Agile. In no time, you will follow a simple framework and will surely be delivering software faster and better than ever before, right? Well, it's not quite that simple. Agile transitions can be difficult, sometimes costly, and a lot of work! Transitioning to Agile is as much about organizational change, empowering your teams, and a mindset shift as it is about changing the way your teams do their day-to-day work. This will prove to be a lot harder than following a simple Scrum framework. On the flip side, strong Agile teams will be more engaged, deliver better software, and stay more in tune with their customers. There are a few things that will help you, as a manager, through this transition.
The Creative Economy
The Creative Economy is a concept defined in a book, published in 2001 by John Howkins, that prioritizes innovation and empowerment of employees to drive the creation of business value. Many of the principles that have been defined as essential to the Creative Economy are also shared with Agile, and I would view embracing them as essential to changing the way your teams work.
In 2015, Scrum Alliance®
created a Learning Consortium to explore some of these concepts and companies that are thriving under these principles. You can read the full report here: https://www.scrumalliance.org/why-scrum/learning-consortium/learning-consortium-report-2015
. Of particular note in the report is this quote:
A universal feature of all the site visits was a recognition that achieving these benefits is dependent on the requisite leadership mindset. Where the management practices and methodologies were implemented without the requisite mindset, no benefits were observed. Individually, none of the observed management practices are new.
Organizations often see a dip in productivity as their teams start adopting Agile. Why is this? You are asking teams to change the way they work. For many team members this may be entirely new, and it may include failures along the way. Failure from experimentation is OK, and should even be encouraged, as long as the team reflects on what happened and figures out how to do it better next time. You may have reorganized your teams so that they are cross-functional, and any change can be difficult if there are established norms and social contracts in your organization. Communicate to your teams why you are asking them to change the way they work. Keep the pulse of your teams by maintaining regular contact with them throughout the transition. Listen to their concerns and address them head-on, and collaborate with them to create working agreements.
Roles and responsibilities have changed
There are some new roles in the organization now: the product owner, who maintains the overall product or project backlog; the ScrumMaster, who is your team coach and facilitator; and the development team, who will build the product and choose what to build each sprint. Ideally, this team will become completely cross-functional SMEs, contain every resource for development within five to nine people, and release new features every two to three weeks. Often additional expertise that the team doesn't have is required, but it may not make sense to have these experts on board full-time. Examples include security, UX, and architecture; these additional resources should be embedded in the team on a non-permanent basis, when they are needed.
The manager's job has changed, too!
With Agile teams, the manager should empower the teams to run their software development process. Ensure that the ScrumMaster is enforcing the Scrum roles, rules, and artifacts and encouraging the team become self-organizing, making all of the decisions that affect them and the delivery of their releases. The manager should ensure that the team has what it needs to succeed and trust them to execute.
The manager's job is to now lead and coach the team for success, providing regular feedback to the team and the individuals; to assist the ScrumMaster in removing any impediments that the team cannot handle themselves; and to assist the product owner with stakeholder management and backlog refinement. The goal for the manager should be to support the team's move from being managed to being empowered, and onward to becoming a self-managing unit. To do this, the manager must abandon any previous command-and-control habits lingering in their muscle memory and focus on coaching the team.
Focus on outcomes, not outputs
One of the tenets of the Agile Manifesto is "Working software over comprehensive documentation." Focus on delivery of customer value over all other metrics, and be very cautious of which metrics you do measure. Empower the team to self-organize and figure out how
and, with the product owner, what
to build. With metrics, what is measured is managed, and this is where the team will focus their attention -- if they are judged only on their velocity, then quality and value will certainly suffer. There are many potential metrics to measure, but for a team moving to Agile, simple is best. A good signal of the health of an Agile organization is the frequency of product releases to the customer.
I hope this has touched on some of the issues you will face as a manager leading your teams through an Agile transition, and that it has given you some food for thought. I will leave you with a TED talk on a perspective on what high-achieving teams look like: https://www.ted.com/talks/margaret_heffernan_why_it_s_time_to_forget_the_pecking_order_at_work