All posts by timborn

How Microsoft Dragged Its Development Practices Into The 21st Century

Aug 13, 2014

An interesting article on ARS Technica on Microsoft’s journey with scrum: “How Microsoft Dragged Its Development Practices Into The 21st Century

It’s worth the read, but here’s the condensed version, with annotations.

Increase Frequency of Delivery, Shorten the Feedback Loops

MS Visual Studio was delivering to production every two years, and they were considered “fast” by comparison (most other MS products were on a 3-year release cycle). Customers’ expectations changed. No longer was it acceptable to report a bug or request a feature and wait, on average, three years before seeing any feedback. Now this team is releasing updates to production every three weeks.

“With the new process [scrum] in place, the Visual Studio team has been able to build better software and deliver it more frequently. It’s now approaching its 70th successful three-week sprint. TFService, now rolled into a broader suite called Visual Studio Online, has a service update every three weeks, putting new capabilities and features into users’ hands on a continuous basis. On-premises software hasn’t been forgotten either. The sprint-based updates are rolled into quarterly updates for the on-premises TFS.”

Lower the Lake, Expose The Rocks

Frequent delivery to production, while useful in itself, is useful even if you don’t take advantage of it (you don’t go to production, but you have made it production ready every sprint). That seeming contradiction is captured in this observation from the Microsoft Visual Studio team after they switched to scrum:

“The need for regular iterations has also caused improvement to some unsexy parts of the software. The setup and upgrade process for Visual Studio was annoying and complicated, with a large testing matrix to handle upgrades from various different versions. With an iteration every three weeks, this situation was set to become intractable. Because setup and upgrades are done every sprint, the system needed to be more robust and easier to test and manage. The agile process motivated that work, and the result should be that upgrading end-user machines is less disruptive and prone to failure.”

Putting this another way: “If It Hurts, Do It More Frequently, and Bring the Pain Forward.” – Jez Humble. The knock-on effect on your organization and it’s processes is important because by shortening the cycle time for delivery we stress/improve the most important parts of the value stream, the one that holds us back from increasing the flow of value to our customers. Nothing else has the same laser focus for cutting through the noise as does shortening the delivery cycle times.

Internal Open Source Code

“Microsoft is traditionally viewed as a series of fiefdoms, with each team jealously guarding its own work and not sharing with others. As such, people in one team have historically had little access to other teams; they couldn’t see what they were working on or the source code they were producing.” [an example of Conway’s Law, where the org chart ends up reflected in the code]

“… source code is now viewed as a shared resource. If people in the Bing team, say, want to look at the Windows code, they can. Further, we’re told that if they want to fix something in the Windows code, then that too is possible …”

The Dark Side

Microsoft recent announced the largest round of layoffs in their history.

“…one victim group appears to have been the dedicated programmatic testers in the Operating Systems Group (OSG), as OSG is following Bing’s lead and moving to a combined engineering approach …

Obviously they still have some lessons they haven’t yet assimilated. One would have preferred the lean value of ‘job security, not role security’ to be applied. It’s insane to think employees will willingly engage in adopting practices that improve things for the company if they believe they will lead to their own demise. There is a limit to corporate loyalty.

Other

Other items of note: the changes to the physical space to allow teams to collaborate much more effectively, the photo of the working agreements for one of the teams posted on the whiteboard (page 3). While Microsoft has largely adopted scrum bottom up, they appear to be hitting the limit of the benefit and are now feeling pressure to become a more agile organization. The implications of that will be hard for their management team to swallow, but entertaining to watch … from the outside.

Scrum Masters Don’t Do Performance Reviews

Apr 4, 2014

The notion that a Scrum Master should in any way review teams or team members goes against core scrum.

‘… when it comes to [Scrum Master] … participating in the annual appraisal, ratings, or rankings, my answer is “No. No. No!”

Thoughts from Esther Derby, author of Agile Retrospectives.

The assumption that the team (or individuals) should be reviewed and rated by the Scrum Master is toxic to transparency and the servant-leadership relationship of the Scrum Master.

Teams have the following characteristics: They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality; (scrum guide, p. 5)

The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. (scrum guide p. 6)

The Scrum Master’s job is to work with the Scrum Team and the organization to increase the transparency of the artifacts. This work usually involves learning, convincing, and change. (scrum guide, p. 15)
Thoughts from Mike Cohn, founder of the Agile Alliance:

“Many who are new to the ScrumMaster role struggle with the apparent contradiction of the ScrumMaster as both a servant-leader to the team and also someone with no authority.”

“… the ScrumMaster’s authority does not extend beyond the [scrum] process …”

The idea also assumes that people need to be measured and commanded in order to do a good job (Theory X).

The 5th Agile Principle encodes Theory Y:

“Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.”

Let us avoid ScrumBut. (“We use scrum – but our Scrum Masters rate the team or team members”)

dilbert-on-trust

Digging Deeper

Digging deeper to find the question-behind-the-question, we might ask “how can we ensure teams e.g. implement Architecture 2.0 even when the Product Owner neither understands nor cares? (or worse, the PO is actively lobbying for short-term solutions).

If THAT’S the problem, then consider:

  • this is a systemic problem that requires a fix to the system, not a local fix
  • it is not resolved by having the SM review teams or team members; that will just make things worse for the team

There are some things that we (management) are able to declare as “required”. We need to make those items painfully clear and unambiguous. Furthermore we need a conflict resolution protocol that will allow teams to get relief rather than dialing up the stress. Given the immaturity of some of our Product Owners it seems this sort of conflict is inevitable.

Is the Impediments Removal Service this conflict resolution protocol? Should teams that find themselves caught between a PO short term demand and e.g. Architecture 2.0 raise this to the management team to sort out? Given the power relationship between the Product Owner and the teams (teams work for the PO; we’ve given the PO input to performance review), then when these sort of conflicts arise, senior management need to step up and address them, not create a situation with conflicting messages and high stress for the teams.

Rotating Scrum Masters

Feb 5, 2014

I occasionally see teams that rotate the Scrum Master role. These are usually teams new to scrum, with no real appreciation of what a Scrum Master really does. Sometimes few are interested in signing up for a role so ill-defined (in their mind), so rotation is a way to “share the burden”. Other times we have an abundance of people who want to be Scrum Masters, often predicated on some misunderstanding, and rotation is seen as a way to be “fair” and avoid conflict.

Rotating the Scrum Master role is problematic. Once you understand the depth and breadth of skills required to be a journeyman SM, and the amount of learning necessary to be even moderately successful, it will become quite clear this is not a role that can be tossed back & forth like an old sweater, worn for a sprint and handed on. A Scrum Master is a master of scrum.

“Some teams that struggle with choosing the best ScrumMaster decide that an appropriate strategy is to rotate the role among all team members. I don’t advocate this, as I don’t think it demonstrates an appropriate respect for the challenges and significance of the role.”Mike Cohn, founder of Scrum Alliance, author of several books on scrum.

Rotating ScrumMaster is perhaps always a bad idea. It indeed dilutes the ScrumMaster role. A good ScrumMaster has 4 “focus areas”: Team, PO, Organization, Dev Practices. However, what happens if you have a rotating ScrumMaster is that he only starts focusing on the team and the PO/Organization suffer.” – Bas Vodde

“The skills of a good SM are quite different from those of most team members and from what I’ve witnessed when a team member takes on the SM role, they tend to focus on the team and often even want to somehow continue to be a part of the team.” – Stuart Turner

The solution seems to be more education on the role of the Scrum Master, and exposing these teams to some good examples of SMs living the agile values and helping their teams & Product Owners.

Waste

Dec 03, 2013

Lean is an idea that puts the customer front and center. Applying lean thinking to a system one views every activity through the lens of “is this valuable to my customer?”. Put another way, one could ask: would a customer pay us more to do more of some activity? Everything that is not valuable in lean is termed waste.

Waste is not a pejorative, it’s a statement of fact. We should learn to recognize waste and try to minimize it.

“To eliminate waste, you first have to recognize it. Since waste is anything that does not add value, the first step to eliminating waste is to develop a keen sense of what value really is. There is no substitute for developing a deep understanding of what customers will actually value once they start using the software.” – “Implementing Lean Software Development From Concept to Cash“, Mary and Tom Poppendieck.

Attempts to redefine technical terms indicate either a lack of understand of lean thinking or a desire to reduce transparency through obfuscation.

See also “Lean Software Development“.

Sprints Versus Release

Jul 21, 2013

A common source of frustration occurs when people, especially Product Owners (PO), realize that what they can expect from a single sprint is nothing like what they need to release. They want it all. Anything less is useless.

What the business wants in order to ship the product is called Minimal Viable Product (MVP). The sum total of features that the PO has determined is worth presenting to our customers.

At the end of each sprint the team should have a Potentially Shippable Product Increment (PSPI).

The relationship between PSPI and MVP is that MVP is the sum of several sprints worth of work.

MVP = ∑ PSPI

The “potentially shippable” part is really important because that allows the PO to change direction at any sprint boundaries, or to release earlier if they choose. That phrase also drives the organization to break down the waste of hand-offs between silos, driving testing into the sprint. Sutherland reported the effort to test, even one sprint later, was 24x the effort to test during the sprint. He also pointed out that breaking down this barrier is probably the single best thing you can do to improve your organization.

Q: My business users don’t see any value in intermediate deliverables and in their eyes MVP is equal to a fully delivered product. Why bother with PSPI?

A: This is a common situation before PO understands (and trusts) the tech teams. Their mind is still in the contract game and they want to push responsibility not only for development but also prioritization and conflict resolution into the tech teams.

Even for deeply technical stories with no UI we have found ways to demo the work. Always try to pick a slice that goes as near end-to-end as you can. To the extent the scrum teams can deliver PSPI every sprint that have got working code much earlier and the integration effort is amortized over a longer time (big bang integration often leads to lots of OT and pain, as you probably know). Scrum teams should absolutely drive for PSPI even when the PO doesn’t seem to care, because the effect of that construct is good for the product and exposes weaknesses in the processes & tools in place.

Every situation is different, but demonstrating working code that is incrementally better every few weeks is a compelling draw for many people, so even if your PO is intransigent now we should hold the line and be agile because we see the benefits.

See Also: “Why Longer Sprints Probably Won’t Help“.

It Gets Worse Before It Gets Better

Jun 21, 2013

Satir Change Chart

Virginia Satir was a psychologist. She studied (among other things) how groups interact under the stress of change. The picture above is a typical Satir Change Diagram.

When you give it a quick look, time is shown along the X-axis. You see the group/team/organization is operating at some level before some “foreign element” or “change agent” appears and changes the system, throwing the team into a state of chaos. The team flounders in chaos, but if they persist they can climb out the other side, presumably to some higher state.

What does this imply for adopting scrum?

There will be pain. It will get worse before it gets better.
Corollary – if you aren’t feeling the pain, you probably did something wrong (see Larman’s 2nd Law)
The state on the other side better be worth all this pain!
While in the “chaos” state, the desire to retreat is large. The longer you flounder in chaos, the stronger the desire to backpedal.
… therefore, cross the chaos gap as quickly as possible.
Adopting incremental bits & pieces guarantees maximizing the pain and minimizing the chances of getting across the painful chaos.
get help to pull your team(s) across

Viewed another way, this is a restatement of the Tuckman model (forming/storming/norming). Both are cyclical in the sense that this is a reoccurring pattern that teams will progress through as they grow in maturity.

Interestingly, Virginia Satir was noted for her work in family psychology.

Skills Versus Competencies

Apr 09, 2013

“A competency is more than just knowledge and skills. It involves the ability to meet complex demands, by drawing on and mobilising psychosocial resources (including skills and attitudes) in a particular context.” [1]

“Competencies are learned over several years. Skills are learned in a matter of months” [2]

How many times do we interview for skills rather than competencies? How often have we seen people with impressive resumes, unable to pull it together and synthesize new ideas into working solutions? It’s a common problem, likely caused by being unaware of the distinction between skills and competencies. Because skills are easy to test, we test for them, but because competencies are much more deeply ingrained in the person, it’s very hard to expose competencies during interviews.

What are some of the skills in the workplace?

Basic Workplace Skills, per U.S. Department of Labor, which surveyed business, organizations, unions to determined that workplace competency depends on 36 skills.

1) Reading 2) Writing 3) Arithmetic / Mathematics 4) Speaking 5) Listening 6) Creative Thinking 7) Decision Making 8) Problem Solving 9) Seeking things in the mind’s eye 10) Knowing how to learn 11) Reasoning 12) Responsibility 13) Self-esteem 14) Sociability 15) Self-Management 16) Integrity / Honesty 17) Time 18) Money 19) Material and facilities 20) Human Resources 21) Participates as a member of a team 22) Teaches others new skills 23) Services clients / customers 24) Exercises leadership 25) Negotiates 26) Works with diversity 27) Acquires and evaluates information 28) Organizes and maintains information 29) Interprets and communicates information 30) Uses computers to process information 31) Understands systems 32) Monitors and corrects performance 33) Improves or designs systems 34) Selects technology 35) Applies technology to task 36) Maintains and troubleshoots equipment

Competencies are composed of various skills, but also pull from a deeper psychological well related to who a person is.

Consider a Scrum Master or an agile coach, charged with both technical skills and “soft” interpersonal skills to deal with team dynamics, using persuasion as the weapon of choice. What competencies might we be looking for? Lyssa Adkins talks about this in “Coaching Agile Teams” and has this chart:

agile-coach-competency

Lyssa says: “You need to be quite strong in Agile-Lean Practitioner and strong in either Mentoring or Teaching as well as strong in either Professional Coaching or Facilitating. We suggest you pick one in-depth area to really get to know: Technical Mastery, Business Mastery or Transformation Mastery.”

That resonates with my experience as well. Too often we have “specialist” coaches who are one-trick ponies. An agile coach or a solid scrum master needs to be able to cycle across several dimensions and up and down the org chart quickly and comfortably.

How can we possibly interview for such competencies? Consider just a couple of the competencies:

Facilitating: A neutral process holder who guides groups through processes that help them come to solutions and make decisions.
Agile-Lean Practitioner: Applies agile practices, lives agile values.

Remember the old adage: not everything that counts can be measured. It would appear the only reasonable way to determine competencies would be to observe someone in action.

References

[1] Salganik, Laura. 2001. “Defining and selecting key competencies”. Kirkland: Hogrefe & Huber.

[2] Aje Cunningham aje.cunningham@stlfsc.org, http://www.slideshare.net/Analystfn/COMPETENCIES-VERSUS-SKILLS

[3] “What Work Requires from Schools; A SCANS Report for America 2000,” Apps. B and C

Perfection Vision

Mar 11, 2013

When explaining scrum / agile concepts / lean to teams, I often wish to establish the perfection vision as an agreement on where we want to be. Someday.

Once we agree on where we want to be, then we back off as little as possible to a point the organization thinks it can swallow today. The gap between perfection and today suggests impediments that should be exposed. Work with the team to find out why we cannot do everything we need to do to be at the perfection vision state. That list of impediments should be added to the organizational impediments backlog. This backlog is rarely discussed, but incredibly valuable as another “learning” feedback loop. The management team is responsible for working through these backlog items so the whole organization can continue to improve over time.

The understanding has to be that we are constantly, relentlessly trying to improve, to reach the perfection vision. I’ve seen teams that accept the impediments without even recognizing them and remain statically stuck in an inherently inferior state. With learning, there is hope. No matter where you are on the continuum of improving, as long as you are able to learn and improve, you can become great. Without learning there is no hope.

An interesting thing that commonly happens with teams is, if I’m not careful, they mistakenly assume that my discussion of perfection vision is a sign of intolerance, ignorance or worse. I have to remind myself to explain “perfection vision” and where it fits in the larger discussion, or I frequently find minds closing quite rapidly.

When discussing perfection vision with teams, slow down and explain more so they don’t mistakenly assume your perfection vision means you are advocating some unworkable solution as the next step.

Design Workshops

Oct 17, 2012

What is the purpose of a design workshop? Some think the purpose is to produce some document or other artifact. In truth, the purpose of a design workshop is to develop a common understanding and to communicate ideas among those attending. The artifact is secondary to creating a common understanding and vocabulary.

design_workshop_shanghai

Scrum does not talk about how the team knows how to build things. Some team assume that because the Scrum Primer is silent on this, it means there can be no design. Au contraire! Design workshops spring up as needed as part of the solution to a Product Backlog Item (PBI). Occasionally, as part of story splitting, a team may use a design workshop to think through how a story may work in order to gain better understanding. That understanding translates into the estimation for the subsequent PBIs in the Product Backlog.

What is required for a design workshop? A problem and a design space. Massive whiteboards are great. The larger, the better since you want everyone to be able to see what is happening and be able to approach the board and contribute. Small drawing spaces and electronic tools kill the interactive nature of design workshops, and the degrade from collaborative to lecturing by a few and boredom by many.

Agile Principle #6: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Relative Versus Absolute Estimates

Sep 14, 2012

A common question is “How should Product Backlog Items (PBIs) be estimated?”. Some will assert story points are the correct answer, some find comfort in using days & hours.

The correct answer is: scrum is silent on this question. “Scrum … does not define an estimation technique.” – Scrum Primer, p. 8

While I appreciate that people are more comfortable estimating using days & hours (“it’s the way we have always done it”), I believe absolute estimates mislead us and often force dysfunctional behavior. Relative estimation should be our preferred choice here. There is ample academic research (ref?) to support the well known problem that developers cannot estimate well. The causes are manifest: software is quite complex, we often make invalid assumptions, optimism often skews our views, we rarely have mechanisms to learn from our mistakes, etc, etc.

The further out in time we look, the poorer our estimates will be. This is why sprints are short, so we can detect and correct frequently.

Relative estimates play to human psychology. Even small children can size up two objects and decide one is twice (or three times) the size of the first, without knowing the slightest bit about absolute units of measurement. Story points leverage that bit of human insight and allow us to get the PBIs sized, relative to each other, in a way that is useful for release planning.

The beauty of relative estimates really becomes apparent during sprint planning. Based on a team’s velocity (average points completed over the past three sprints) the team picks PBIs that add up to about that amount of work. This is a self-correcting system! If a team does well/poorly, the velocity will trend up/down and the amount of work accepted into a sprint automatically adjusts. This also gives us the ability to predict the future with our release plan, based on empirical evidence of progress (working code). If we estimate PBIs in days & hours, the team will feel compelled to pull in as much work as there is time in the sprint, regardless of the team’s actual velocity. The pressure to over-commit is not at all subtle here, and should be avoided.

“Velocity is the way they naturally account for the difference between an ideal 8 hour workday and the hacked-up, interrupted, full-of-meetings, occasionally longer-lunch, day. Team velocity represents the team’s capacity with all the messy details of real work situations already accounted for.” (Erickson)

Since every team will normalize to their own reference unit (“how long is a piece of string?”), there is no way to compare two teams to each other. In other words, a team with a velocity of 25 cannot be compared to a team with a velocity of 12. We are interested in predictability, and eventually helping the team walk their velocity upward, but one should be careful that velocity is a terrible metric and is trivially gamed. If you want the truth (transparency) you have to be prepared to accept an answer without causing a negative feedback loop.

Avoid absolute estimates for Product Backlog Items and learn to manage a release plan using the velocity of your team.