The Scrum Team stuff is Easy (Sort Of)

Scrum has its roots in team empowerment. From the very beginning, teams are told to make their own decisions – “let the team decide what to do” is the oft-repeated mantra when a team faces a challenge.

These ideas can seem foreign to teams that have been told exactly what to do and how to do it. While the route to becoming a truly high performing agile team will take time and effort, much rests on the team’s shoulders and its ability to constantly improve.

Much has been written about the Scrum team, on techniques, tools, and processes. However, a successful agile transformation outcome also rests in properly educating and engaging the senior decision makers in an organization.

Don’t forget about Stakeholders

It’s easy to transition development teams to take on more agility, but if stakeholders, who are often the senior leadership roles in the organization may get left behind or ignored while the rest of the organization shifts.

To many, the idea of an agile business makes sense – react to change, get stuff done quicker, etc. But few know what implementing and living with an agile process looks like, and are likely unprepared for the amount of extra work this may involve.

Stakeholders are often stuck with traditional business metrics, demand cycles, shareholder reporting, thus need the answer to basic questions like “when can I get this?”. They are not prepared to be answer the question, “what set of functionality would you like to see in 2 weeks?”.

This leaves them in a potentially awkward spot. Since the rest of the world outside of the organization is going to be deadline-driven, there can be a significant communication and expectation gap between the development team running in an agile fashion, and the stakeholders not.

Don’t Bother Me with the Details

The stakeholders often just want things done by a certain date. Good agile teams get very specific about what done means, but that does not match the stakeholder’s view of doneness, which is when I can actually start using it. They don’t care about the journey, just the destination, whereas the agile team is constantly plotting its journey, re-evaluating, and re-planning, open to constant feedback.

Stakeholders just want to be able to set the destination and to not get bothered until it’s done, thanks. The whole reviewing of partially done items and having to provide feedback after every sprint seems like an imposition. Worse is answering the above question of what limited functionality they want to see at the end of the sprint when they already have a vision of the whole system in mind.

Stakeholders stay in the traditional mindset, expecting huge returns from some abstract corporate agility initiative, and are blindsided by increased expectations of their time, and see what may seem like slow progress towards a goal. Their expectations were of projects having a single kickoff meeting, followed by months of development work, an occasional status meeting, inevitable delays, and delivery of some sort of system at the end that sort of works. Instead, they get involved in much more regular touchpoints, probably fielding questions daily, and having to assess works-in-progress and provide feedback to the team.

But at least that old mindset didn’t really involve them too much and isn’t that how software works, anyway?

Reality Check

This has been the largest dynamic change I’ve encountered in my experience. A company may like the sound of agile, but often leadership does not invest the time in learning what this means to the organization structure.

An agile team’s greater transparency about their progress and their need for better communications can get shut down by upset or confused stakeholders very quickly with damaging consequences to morale and collateral damage to the organization’s agile initiatives.

Adequately assessing the overall organizational level of maturity and knowledge around what agile means is essential when implementing agile. Here are some reasons:

• Agile is a different mindset. The mindset is to be eternally curious, dynamic, and creative. There are often no easy answers to a problem, and the only answer may be to “just try our best guess at it” and see how it works out. Agile is about giving up control, at least in the traditional org chart sense (But was there really any control, or just an illusion of control?)
• An agile organization is made up of interconnected, small teams working together to deliver value quickly. These teams work towards a common goal. Agile teams continuously refine what they do to get better, and are supported by leadership to keep reinforcing this culture
• Agile organizational goals are often stated as customer goals, as meeting the customer’s unmet needs is what will help define the activities the organization will undertake. Leadership must ensure that teams are focused on these goals to eliminate wasted effort. Focusing on the customer also allows teams to deliver exactly what is needed, and no more.

Laying down these baseline philosophies across the organization, creating partnerships between stakeholders and teams, then living them on a day-to-day basis is what will help create success in an agile transformation.