The Manager and Agile

In a recent post by Michael Sahota, he challenged an assumption the company hierarchy stands in the way of achieving a great agile culture. Michael counters that the way we hold hierarchies within ourselves is in fact the real challenge. While looking at his post it occurred to me our first 18 years of life were spent deeply imbedded within hierarchies. As people, we are fully evolved to live within the hierarchies life puts before us. Here are a couple thoughts on the topic of hierarchies and how we learned to live and expect them. I’d be happy to hear your points of view.

Our Earliest Days

“Leashed children” (CC BY-SA 2.0) by danoxster

When we’re young, very young,  ... Read more here  (https://www.improvingagilepractices.com/2019/03/11/the-manager-and-agile/ )

Tweet

Organizational Adoption of Agile

From Craig Larman - Larman's laws of organizational behaviour:

 

1.       Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and "specialist" positions & power structures

2.       As a corollary to (1), any change initiative will be reduced to overloading the new terminology to mean basically the same as status quo

3.       As a corollary to (1), any significant change initiative will be derided as "purist" and "needing customization for local concerns" -- which deflects from addressing weaknesses and manager/specialist status quo

4.       Culture follows structure.

i.e., if you want to really change culture, you have to start with changing structure, because culture does not really change otherwise. and that's why deep systems of thought such as organizational learning are not very sticky or impactful by themselves, and why systems such as scrum (that have a strong focus on structural change at the start) tend to more quickly impact culture. John Seddon also observed this: "Attempting to change an organization's culture is a folly, it always fails. Peoples' behaviour (the culture) is a product of the system; when you change the system peoples' behaviour changes."

 

I think that those who believe Agile and Scrum are the way forward will be at odds with most businesses that have a deep institutionalized Command & Control structures that rests responsibility, but usually not accountability, within groups/committees while diverting responsibility away from individuals. In Scrum we rest most responsibility on the Product Owner and hold this person accountable for the business value delivered at the end of each and every sprint. It is often this simplicity Scrum provides that is in direct conflict with the ‘status quo’. So how to begin changes to the existing structures?

 

First and foremost, you must have an Executive Sponsor. Without Executive Sponsorship your attempt to directly adopt Agile will almost certainly fail. This is more than just having managers that agree to allow you to use Agile; this is a person who has the rank and status in the business structure who can influence the often many groups/committees who collectively and traditionally have controlled projects.  Agile is a movement that requires top-down leadership to say ‘this is going to happen, here is why it is good and we should all start rowing in that direction.’ The Executive Sponsor, along with possibly one or more Agile Coach specifically trained and experienced in agile adoption at the executive level, will be handing out the oars.

 

What if you have no Executive Sponsor or the Executive Sponsor’s influence is severely limited? Under these circumstances, full Agile adoption is very unlikely to happen. However, there is a strategy that could overcome the tremendous obstacles that are in the way but it does depend on you finding some in Mid to Upper level Management more interested in results rather than institutionalized processes. The ultimate result is usually a hybrid adoption of Agile where all or some of the institutional controls remain in place but an Agile sanctuary is carved out with fewer of these institutional controls than a traditional waterfall project. This hybrid Agile project is not truly Agile but neither is it true waterfall. The strategy follows a bottom up Agile Adoption approach that will take time, maybe a lot of time, to slowly chip away at the traditional structure and replace it with an Agile structure and Agile mindset.

 

The strategy is twofold:

1.       Target getting support from managers in the organization that are more likely to support Agile; and

2.       Target going around the organizational structure of “over seers”

 

The strategy includes targeting those executives in middle to upper management that are more likely to support an Agile process and have some influence on those in the organization who are stanch supporters of the institutional controls. The idea here is not to change these people completely over to the Agile mindset but rather get these targeted managers enthusiastic enough about Agile so they can see the possibilities and potential of Agile. Targeting managers who don’t have influence over supporters of the processes or targeting managers who are the stanch supporters of the processes is usually a tactical mistake. Targeting a manager who doesn’t directly influence those in control of the processes might be an easy convert but other than a quick burst of satisfaction, the real battles will still lie ahead. The manager who is a supporter of institutionalized processes is very difficult to convert; they probably believe in their familiar processes and controls much like you believe in Scrum, albeit for different reasons. A word of caution, because you’ve gotten some support for your Agile project, you must remember that “success has many fathers, failure is an orphan.” For those in middle to upper management who supported you earlier, to ensure their continued support of Agile and endorse its use, hybrid Agile projects must succeed and succeed “loudly”. If your project fails or succeeds but with only a whimper, some, most, or all middle to upper manages may forget that they ever supported Agile.

 

The second part of your Agile adoption strategy will be to identify all those organizational groups and individuals who traditionally sign-off on projects and find a way to exempt the Scrum project from these. These groups are those who sit on gate committees, steering committees, technology committees, or any one of a dozen other committees that approve, sign-off or use other mechanisms of “over-seeing” a project. These groups are often a source of power and prestige for its members and are traditionally very difficult, if not impossible, to get around without an appropriately positioned Executive Sponsor. The best way to get around these groups is to make your project a separate business unit that answers to the CEO/board. This follows along how IBM built its PC division in order to get out from under the bureaucratic thumb of IBM’s corporate structure.  Another tactic is to chip away at the required process these groups require projects to follow. This can lead to some relief for the project but will probably not succeed at allowing full Agile adoption for quite some time.

 

Is doing a Hybrid Agile Scrum adoption good? The short answer is yes. By simply following the activities defined for Scrum, (Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective), Jeff Sutherland has said that this will increase productivity by 20%-30%. However, the greater benefits of Agile are really attained through following of and embracing the deeper meanings of the Agile Manifesto, the Scrum Guide, and Scrum Primer. To become “hyper-product” would require everyone involved in the project (managers and scrum teams) to believe in and live Agile and Scrum. Unless the Mid to Upper level Managers of the business are only interested in results and don’t really care how you achieve them, your best approach to adopting Agile is incrementally, one step at a time.

 

Craig Larman is co-author of:

• Practices for Scaling Lean & Agile Development: Large, Multisite & Offshore Product Development with Large-Scale Scrum
• Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum
• Agile and Iterative Development: A Manager's Guide

Tweet

Agile Project Manger or Scrum Master?

I find that there's a tremendous amount of prejudice against certain words in the Scrum community and "manager" is near the top. A business can and will give their roles any title they feel is appropriate. I would bet the farm that in some companies, the Scrum Master role is more aligned to a Project Manager of old and that Agile Project Manager role is more aligned to the Scrum Guide’s definition of the Scrum Master. So far no help, right?

Most businesses that are or will be transitioning to Scrum will have an Agile champion on board to guide the transition. I was this person at my previous company and after some time the role of Scrum Master was identified and added to HR’s list. However, before that happened, the person in the Scrum Team coaching and helping the developers and product owner was known as “Scrum Master”. This happened due to training and coaching the software and product management departments received during the transition to Scrum. The internal view was that the servant-leader of a development team was called “Scrum Master”. The external view of the role as projected by the HR department, possibly following 10 – 20 years of tradition, might have still have the role listed as “Project Manager” but now with the added term “Agile” plopped in front. This shouldn’t be too much of a surprise as the adoption of Scrum starts within the software department and will only spread once the successes due to the application of Scrum are recognised. As the Agile champion, my focus was on the software department and not HR, (in the beginning). After a couple months and Scrum had an obvious foothold in the company, efforts to re-align HR roles and role descriptions (Scrum Master, Development Team Member, Product Owner) began.

 

As a practicing Scrum Master and I saw a job ad that said, “Agile Project Manager”, I would apply with the knowledge that the role is most likely that of a Scrum Master for a company in transition (or possibly stuck in transition). I might find out otherwise at the interview but that’s the point of the interview: the prospective employer and prospective employee determine if there exists a common understanding of expectations and responsibilities surrounding the role. Some may see this as waste but as the interviewee, I see interviews as a learning experience even when the ultimate outcome is no job.

One of the responsibilities of the Scrum Master in the Scrum Guide is, “Leading and coaching the organization in its Scrum adoption”. This is where it can be argued that the Scrum Master is charged with aligning the roles and role descriptions in HR with the roles and descriptions found in the Scrum Guide. If the Scrum Master(s) are unsuccessful in doing this today, then it means they try again tomorrow, and the next, and so on. As long as the internal application of Scrum roles is correctly aligned with the Scrum Guide, then this view external of the Scrum Team might be an annoyance but not necessarily a terminal problem.

 

Summary

 

In the final analysis the Agile coach and Scrum Masters need to pick their battles with an eye on impact and results. Getting management and the Scrum Team following the Scrum framework is to me, job one. Pulling the rest of the corporate structure in line with Scrum role descriptions i.e., HR and management, is of secondary concern in my view.

 

 

Tweet

Measuring the Success Of The Scrum Master

The Scrum Guide states, "[T]he Scrum Master is responsible for ensuring Scrum is understood and enacted." Scrum is defined in the Scrum Guide as follows: "Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value." So, one could logically conclude that the scrum master role is responsible for ensuring the scrum team is "productively and creatively delivering products of the highest possible value." I think that the CEO, CTO, Development Department Manager will particularly note the "highest possible value" aspect of the scrum master role and want to know if the scrum master is coaching the team toward this goal. Here are a few points to track the success of the scrum master:

• Is the scrum team (development, product owner, and scrum master) following the 12 principles of agile as defined in the agile manifesto?
• Is the scrum master ensuring the scrum team (development, product owner, and scrum master) is following the rules of scrum as defined in the scrum guide?
• Is the scrum master helping those outside the scrum team understand agile and scrum?
• Is the scrum master protecting the development team from interruptions?
• Is the scrum master removing obstacles and problems affecting the scrum team e.g. getting better computers, coffee, baby sitters, listening to problems ...?
• Is the development team moving toward being self-organizing?
• Is the development team moving toward being cross-functional?
• Is the development team enjoying work or do they dread coming to work?

I think most measures for scrum master are subjective but that really means you must exercise greater caution when applying your scientific methods. For example, if the product owner randomly asked ten customers if they liked the user interface to a product and one voiced the opinion that it's bad, then you probably wouldn't change the interface. If however, nine of the ten voiced the opinion that the user interface is bad then this means something even though it's still all very subjective. What the product owner is doing is taking purely subjective measures and objectively applying them to the science of statistics. Could all nine customers be an anomaly with your other 991 customers happy with the user interface? Of course the answer is yes but it's also very unlikely.

 

Measuring the scrum master's performance against the expectations found in the Scrum Guide can follow the same principles as above. For example, measuring the scrum master’s service to the development team in "coaching the Development Team in self-organization", one could use several subjective measures together, with any weighting you choose, and reasonably determine over time if the development team is becoming more, less, or remaining static in self-organizing, assuming the method of measuring and weighting remains constant. These measures might include:

• How does the scrum team rate itself in forming-storming-norming-performing?
• Does the development team pull items from the product backlog rather than having them pushed onto them?
• At the daily scrum, is the development team providing status to the chickens or are they planning the day's work?
• At the daily scrum, does one development team member repeatedly advise others of what work they should be doing?
• At the retrospectives, does the scrum team actively pursue areas for improvement and then execute on these improvements?
• Does the development team often seek outside assist on how to implement a user story?

Enough subjective measures can be found to objectively determine if the development team is self-organizing.

 

What Is Success?

You may often times hear that working software is the measure of a scrum team's success and this is then used to determine the general success of every person in the scrum team, including the scrum master. I would argue that this is not enough since working software doesn't necessarily mean it's valuable. Think about delivering working software after the company had already lost a competitive advantage or delivering working software that no one wanted or bought. It's also conceivable that some customers, early adopters spring to mind, would tolerate software that doesn't completely work in order to see the concepts and the potential of the product. The Scrum Guide specifically allocates responsibilities to the product owner and scrum master with regards to adding value; not so for the development team. I think that "value" in the context of the Scrum Guide is value for the customer and, consequently, for the business. The rules and practices in the Scrum Guide are there to support the 12 agile principles including the very first, "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." It's the scrum master's role to ensure that the scrum team "satisf[ies] the customer" through the “continuous delivery of valuable software". The scrum master does this by making sure the scrum team "adheres to Scrum theory, practices, and rules". It's the responsibilities of the scrum master, as defined in the Scrum Guide, that business can use to measure the success and effectiveness of the person given the role of scrum master.

 

 

 

Tweet

Before the First Scrum: Management

You're a manager, a process person, developer, or product manager and your business success has been OK but you think it could be [much] better if your development strategy switched from waterfall to Scrum. How will you begin the transition? This entry will provide some advice on what needs to happen to convince a reluctant management team of the advantages of adopting the Scrum framework.

First Steps For Management

You've heard it over and over again that management needs to support the philosophy and practical applications of Scrum in order for it to work and be successful.  In my situation, the R&D Manager and Product Management Manager were both experienced with Agile and were eager to experiment  with Scrum to determine if the results would be better than the waterfall methodology then currently followed. The key point was that it was an experiment and not a full commitment; Agile would have to prove itself and that proof would be measured in the quality of the product and the speed at which the delivery was made. The business itself was not fussed on the means but were very keen on the results. Having the two department managers who are directly responsible for new product development supporting Scrum was, I believe, crucial for our ultimate success of adopting Scrum.

But what if there's no management support or worst, opposition to change i.e., adopting Scrum.

I worked at a defence company in the early 80's and the company's policy was no one would be hired as an engineer unless they had a 4 year college degree. My manager wanted to bring in someone as an engineer but without the necessary 4 year degree. The manager ended up writing a memo (remember those?) and eventually got the person in as an engineer. He later told me that the length of the memo was directly related to the hurdles before him and to get the person hired as an engineer required an eight page memo. The point of course is that the bigger the obstacle blocking your goal, the bigger the effort in making your case to reach that goal. To convince management that Scrum is a better alternative to current development methodologies, usually waterfall, you need to make the business case that Scrum can improve both quality and productivity; get better products out to the paying customers more quickly.

You must sell the idea of Scrum to management starting the first day and every day following without letup. Management needs to learn that through Scrum, there's higher productivity, greater innovation, quick reaction to customer or competitive changes, high visibility to progress (or lack of progress), higher product quality, and more potential evaluation deliveries to customers after each sprint. At a training session given by Jeff Sutherland, he stated that even if you do nothing else but have a daily scrum meeting, you should see a 20-30% increase of productivity. Jeff Sutherland has lots of practical information and statistics that can be used to help convince your management that Scrum can help your business. There are also many, many resources on the web that have anecdotes and other stories that can help bolster your arguments for Scrum adoption. You will need to understand what exactly the manager's opposition to Scrum is and address those issues directly.

I also think that trialling Scrum is a better approach than trying to completely change the way things are done all at once. By trialling, management is more likely to allow a single team to adopt Scrum without, in their minds, risking everything. When my company first trialled Scrum, only one team was formed. After the team was able to deliver a new product in only three months, a feat that had never happened before with waterfall, the CEO asked why all of development wasn't doing Scrum. 

If you have any stories on how you succeeded in winning over management to use Scrum, please let me hear from you.

Tweet