Adrian Lander - Agile 2

Yet what usually happens is that development teams are told to create a new set of features and obtain their own test data. How? The production data is usually owned by a business function; so the developers go and talk to the people who support the systems, who have access to the production data, and say, “Can you get us some production data?” That is a very ad hoc approach and is a recipe for problems when the new features go live.

Some organizations have test accounts set up so that development teams can access production systems using test accounts and thereby access production-like data. Organizations also sometimes “mask” or “surrogate” production data to hide sensitive data from development teams. Those are effective practices. The bottom line is that data for testing is a critical need: if development teams do not have ready access, it is the responsibility of the business function that owns the data to help the development teams solve that problem and obtain production-like data.

1 1. agileforest.com/2012/02/26/scrum-evolution-over-time-part-2-roles/

2 2. www.forbes.com/sites/cognitiveworld/2019/08/23/the-end-of-agile/

3 3. apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/

4 4. Elon Musk on how SpaceX designs and tests: www.youtube.com/watch?v=xNqs_S-zEBY

5 5. en.wikipedia.org/wiki/Yerkes%E2%80%93Dodson_law

6 6. medicalxpress.com/news/2016-03-bad-decision-anxiety-blame.html

7 7. Jack Welch; Suzy Welch. Winning. HarperCollins e-books. Kindle Edition (p. 25).

8 8. press.uchicago.edu/Misc/Chicago/027961.html

9 9. en.wikipedia.org/wiki/Dirac_equation#Dirac's_coup

10 10. petapixel.com/2019/07/05/goodbye-aberration-physicist-solves-2000-year-old-optical-problem/

11 11. en.wikipedia.org/wiki/History_of_quaternions#Hamilton's_discovery

12 12. www.cnbc.com/2019/10/14/jeff-bezos-this-is-the-smartest-thing-we-ever-did-at-amazon.html

13 13. www.inc.com/tanya-hall/all-that-collaboration-is-hurting-your-results-heres-why.html

14 14. www.sciencedirect.com/science/article/abs/pii/S0272494408000728

15 15. www.washingtonpost.com/posteverything/wp/2014/12/30/google-got-it-wrong-the-open-office-trend-is-destroying-the-workplace/

16 16. www.bmmagazine.co.uk/in-business/not-all-developers-like-agile-and-here-are-5-reasons-why/

17 17. blog.echobind.com/4-ways-to-optimize-an-agile-environment-with-nudge-management-2adbb2878d9f

If an organization has good leadership, everything else will follow. If an organization has bad leadership, no methodology or set of rules will save you.

Elon Musk's companies have demonstrated not only unprecedented innovation but competitiveness, altering and taking the lead in entire industries. Musk sees innovation as a strategic process to be managed and grown. When Robert Zubrin, president of the Mars Society, asked Musk what it will take to get to Mars, Musk's response was not about rockets or money; his response was about the needed rate of innovation:

“I'm trying to make sure that our rate of innovation increases… this is really essential… if we do not see something close to an exponential improvement in our rate of innovation we will not reach Mars.”1

Zubrin then asked about Musk's methodology. Zubrin said this:

“One thing that is really amazing about SpaceX to those of us who have experience in the aerospace industry is the rate of innovation. Last time you spoke to the Mars Society convention it was 2012. Since then you have made Falcon 9 reusable, introduced Falcon Heavy, Crew Dragon, a satellite constellation, and you're in the middle of developing Starship. What is your methodology that allows you to innovate so swiftly?”

Musk's response was, after a long pause, “I don't really know.”

What makes SpaceX and Musk's other companies so successful and so innovative is not a methodology; it is the leadership that Musk provides.

This is why leadership is the core issue for understanding how a group of individuals can work together effectively. The issue cannot be sidestepped. Bad leadership is often a terrible problem, but dismissing the need for leadership does not solve the problem. We must deal with it head-on.

The Agile Manifesto tried to address the issue of the bad manager by ignoring the need for managers, implicitly saying that managers are not part of the equation. That is like trying to deal with bad friendships by dispensing with friendship. According to Mark Schwartz, former CIO of the US Citizenship and Immigration Service and a well-known Agile and DevOps evangelist,

“The Agile world, ever suspicious of management, proceeds as if it can manage without the involvement of IT leaders.” 2

A manager is, by definition, a leader who has authority. Authority at the top is unavoidable. An organization has owners or shareholders and a board or a government-appointed leader who has oversight. The question is, is authority needed at other levels?

The Agile Manifesto is silent about the role of managers. Typically, in most organizations, a manager has direct staff, and those people are the manager's team. The Agile Manifesto's principle “The best architectures, requirements, and designs emerge from self-organizing teams” seems to advocate that teams do best when self-organized, which implies that managers play no direct role. The Agile community has struggled over the years to figure out how to integrate managers into Agile ways of working.

While the Agile Manifesto was written in the context of software development, the ideas have been applied elsewhere, and the culture of the Agile community strongly reflects the self-organization ethos, regardless of the domain of application.

Yet if successful Internet companies can be a guide, managers and team leads are still very much present at the most successful companies. For example, at Google most development teams have team leads. According to the book Software Engineering at Google ,

“Whereas every engineering team generally has a leader, they acquire those leaders in different ways. This is certainly true at Google; sometimes an experienced manager comes in to run a team, and sometimes an individual contributor is promoted into a leadership position (usually of a smaller team).” 3

The challenge with collective leadership is that authority is sometimes needed, and while a team can collectively have authority, authority requires accountability, and it is difficult to hold a whole team accountable.

The Agile community is right to have anxiety about authority. Traditional organizations use authority way too much. The traditional Theory X model of a manager who dictates how work should be done and expects everyone to follow orders might work fine in some situations, but most of the time that approach works very poorly, particularly when judgment and creativity are important components of the work. We will discuss Theory X and other leadership models in the “Theory X, Theory Y, and Mission Command” section later in this chapter.

Even when work is repetitive and uncreative, allowing people some control over how they do the work leverages their experience with the tasks and also gives them an important feeling of personal control, which boosts morale.

Authority is needed, but it should be used sparingly. Having authority does not mean that you use it . In fact, people often conflate two ideas: (1) autonomy that has been granted and (2) no one having authority. These are not the same. Authority may be needed to cover many situations, but the best use of authority is often to give others a reasonable degree of autonomy.