Managing in Agile Scrum

Being a manager in an Agile environment is a bit like taking your first child home from the hospital. You have a general sense of what you need to do, and a lot of people giving you advice, but no really specific guidelines.  So what’s the best way to make sense of the role?

First of all, it’s normal to feel confused when first managing people working in Agile Scrum. After all, the Scrum framework only includes three roles, none of which is a manager. In fact, it’s common for Scrum Teams to shut out managers because they are not clear what their role is. What these people are missing is that when done right, managers have a lot to offer Scrum Teams, and are essential in the effective running of an enterprise company.

Managers can help drive a high-performance organization by moving away from a command and control mindset to one that is principles driven. This means less focusing on the specific actions that your teams are performing as it is guiding and incrementally improving the system within which the teams work.  Some examples of this might include:

• Support implementing engineering practices like automated testing and continuous integration so that teams can spend less time on routine tasks and focus on creating truly innovative software. 
• Listen closely to teams and remove the structural and process problems that they say are holding them back. This may mean protecting them from disruptions.
• Provide a larger context for your employee’s work, helping them to connect what they are working on into a cohesive, company-wide picture. 
• Design or support work routines that allow for code refactoring – although it would be up to the team to figure out exactly what would be refactored.
• Build a bridge between the product management strategy and what teams can deliver.
• Use Performance Management to align your teams to where the company will need to be six months or even years in the future. For instance, do we have the right people in the right jobs? Do they have the skills and technology they need to succeed?

As a manager, only by combining these various skills together into a web of support for the people you manage will you help them to navigate the rough waters of modern software development. Managers can guide the change the organization needs to be successful. And while you may make some mistakes along the way, that's okay - as long as you take it upon yourself to get better every day, carrying everyone along with you, the organization will be in a better place tomorrow then we are today. Good luck!

Related Posts:
The Paradox at the Heart of Scrum
The Science of Innovation

The Paradox at the Heart of Scrum

"People's ability to participate increases over time if they are developed properly, but giving too much responsibility before they are prepared can cause some real problems."
- Ross Silberstein, former VP and Director of manufacturing, Sherwin-Williams Automotive Aftermarket Division, as found in Kimball Fisher's Leading Self-Directed Work Teams

Agile Scrum is a methodology built upon having self-directed work teams deliver software in small iterations, inspecting and adapting their work at the brief pause between iterations.  A way of working that’s simple to learn but difficult to master, Scrum feeds off of the strength of an engaged team of diverse developers (the theory states that anyone on the team should be able to do the work of anyone else when necessary) and of building confidence that you’re building the right solution though the constant validation of working software at the end of every iteration. In theory, it’s a simple way of working that provides a lot of benefits. I experienced many of these benefits myself working in a small company (>40 people) that built an excellent CRM software product.

And yet over the last few years I've seen nothing but complications in my current work helping with an Enterprise company with its Agile transformation. Some of these changes are perhaps inevitable when you take a system designed for a small team and scale it up to a group of 7K developers – the need for more and more status meetings, planning at ever higher levels to keep the individual development teams in sync with the large company and solution strategy, etc. (There’s even a scaled version of Scrum called SAFe that’s gaining traction with many larger companies.) But the main issue I think is what seems to me to be a paradox at the heart of Scrum: The need for strong individuals to help empower Scrum Teams.

Arguably the most important factor in implementing Scrum is the need to move accountability from the individual – be it a single developer or a general manager calling the shots – to the team or larger group. Scrum requires that the team own their work in a way that unleashes their creativity and passion to solving business problems. The ideal Scrum Team is made up of entrepreneurs who take great pride in their work. However, it’s been my experience that it’s very difficult in a corporate environment to promote this type of ownership without a few strong people leading the way. Call them coaches, guides, or teachers, these people need to bring both a credible and deep knowledge of Scrum as well as charisma (an ability to persuade people) to the table. In short, the teams need to respect this person and her ability so that they want to emulate them.

Many companies feel that they can build these coaches by taking their highly skilled technical people and training them. But faith in technical acqumen does not provide these figures the skills they need to lead people on the journey from individual to team accountability. Knowledge workers have been taught, both implicitly and explicitly, that they are valued for their technical skills. Once we stop promoting employees that are skilled coders into management positions and assuming that this skill alone will ensure success will we move in the right direction. Instead, corporations should be looking for and upskilling leaders – even those that have no deep technical skills – to guide their companies down the Scrum path.  My experience has led me to believe that the necessary skills include a deep knowledge of group dynamics and effective hands-off management (servant leadership, if you will) is the most effective way to get past the barriers to success in larger organizations.  This is a hard skill to teach!

But it doesn't mean we shouldn't try. Developing a cadre of Agile leaders is the key to successfully coaching self-directed Scrum Teams to achieve true independence. Without it, the potential for teams to get caught in an endless storming phase is high. Seems to me like investing in a few Agile coaches is worth the price.

The Science of Innovation

Interesting podcast with John Sullivan, who sparked some new thoughts with his take on the science of innovation. My distilled takeaways:

• Employee interaction encourages innovation. Contrast this with telecommuting/working from home, which boosts productivity and creativity.
• Creativity is idea generation, not innovation. Innovation is ideas implemented in the marketplace. 
• The methods of boosting productivity are totally different than those that improve innovation. 
• There’s a science to increasing innovation. Larger technology companies like Google and Apple are refining these all of the time. And this is why Yahoo recently discontinued it's telecommuting policy. 
• Sullivan paraphrases Larry Page: "if you focus on continuous improvement—or efficiency or productivity, in my terms—if you focus on continuous improvement, you are guaranteed never to be wildly successful because you’ll be so focused on improving by, you know, these small percentages, you’ll never see the big picture."
• Innovation is what's driving the worth of Google and Apple - and is why Yahoo is pursuing it.
• Sullivan mentions the science that large tech companies are leveraging to encourage collaboration, saying that maximizing have done around maximizing collaboration and thus innovation - even going so far as to study the effects of cafeteria lines - but i'd love to see the practical side of this. 

The distinction between innovation and productivity is an interesting one, and one that I hadn't pondered before. So Sullivan says that Google believes that innovation comes from three factors:

1. Rapid learning, or what they call “discovery.” 
2. Collaboration, which occurs when you bump into people.
3. Fun, which when you’re having fun and you bump into employees, you learn and discover." (It's why these companies have so many perks.)

I get the idea that working closely together with someone could drive innovation. After all, it's collision between diverse experiences that spark new ideas. What I don't see is how this collaboration can drive the implementation of these ideas. In my experience, implementing things, requires focus -- heads-down work devoid of interruptions and the random interactions they say innovation requires. They seem like two different things to me. So what's the best way to integrate the two? Do these ideas only apply to software developers?

I'm an Agile Coach. I've been sold on continuous improvement, build up innovation incrementally into something bigger than the sum of it's parts. What Page says above contradicts this approach, and reinforces what I've been realizing recently: that while Scrum works most excellently on a small scale, when you use it on a large scale (like at the Enterprise company where I work), the lack of a big picture can be a huge impediment. I'm also not sure good Scrum is for the ideation portion of large projects, where you need to have a vision and big picture in place before you start. It seems to me that an effective company would be aware of the phase of the project this line of thinking, and adapt their policies accordingly. Something like making sure that all workers are present during planning sessions and other important project phases (reviews, etc.) while being more flexible during the regular work phases.

One last thought. Telecommuting is a godsend for parents. It's a fact of life that schools and doctors aren't configured to accommodate modern life (i.e., two working parents with full-time jobs). Thus, parents like myself need to juggle working with early release days, open houses and teacher conferences, doctor's appointments, early sports practices: the list goes on and on. Without a telecommuting option - I can check and respond to emails while watching soccer practice! - parents would be forced to use sick or vacation time when it wasn't truly necessary. This is the biggest reason why I'll always champion at least occasional telecommuting, and I'm curious how companies who prioritize innovation would respond to this challenge.

Related Posts:
The Paradox at the Heart of Scrum
Managing in Agile Scrum

Why Big Companies Die

I found truth in this article by Peggy Noonan. She makes two basic points. One is from Steve Jobs:

[Jobs] has a theory about “why decline happens” at great companies: “The company does a great job, innovates and becomes a monopoly or close to it in some field, and then the quality of the product becomes less important. The company starts valuing the great salesman, because they’re the ones who can move the needle on revenues.” So salesmen are put in charge, and product engineers and designers feel demoted: Their efforts are no longer at the white-hot center of the company’s daily life. They “turn off.”

Noonan adds "accountants and the money men" to Jobs' theory:

...[they] search the firm high and low to find new and ingenious ways to cut costs or even eliminate paying taxes. The activities of these people further dispirit the creators, the product engineers and designers, and also crimp the firm’s ability to add value to its customers. But because the accountants appear to be adding to the firm’s short-term profitability, as a class they are also celebrated and well-rewarded, even as their activities systematically kill the firm’s future.

When the people that do the work aren't valued, then the products suffer, and what is a company without it's products? It's why I think Agile Scrum is such an effective software development process; by pushing decisions down to the lowest possible level, you let people who are actually informed about the subjects (the "boots on the ground") make informed decisions rather than choosing directions based on executive summaries or spreadsheets. While you have to be careful to keep the focus on the customer (don't let the Inmates Run the Asylum), Jobs demonstrated that keeping a company's focus on adding customer value - another goal of Agile Scrum - is a path to continued success.