Monday, January 15, 2018

Scrum is Mutable

The Scrum Guide has changed a few times, and the most recent revision was published in November 2017. Although a number of people have contributed to defining Scrum over the years, the key parties and primary authors of the Scrum guide are Ken Schwaber and Jeff Sutherland. That Scrum has changed over the years should not come as a surprise to anyone who is familiar with it or with Agile in general. Change is core to Scrum, with 'inspect and adapt' being a key activity for teams. With this comes learning that can at times be universalized and shared with teams everywhere. When it is particularly compelling it becomes part of the Scrum standard.

Scrum is mutable.

Several months ago I was listening to an Agile podcast and end up shutting it off about 20 minutes in because the guests and the host attacked Scrum itself as a bad methodology and then turned around and complained that 'no one does Scrum right.' One guest seemed to think it was downright scandalous that Agile teams at a major corporation he visited didn't even know the Scrum Guide exists. As if they were Christian churches that didn't know about the Bible.

The Scrum Guide is not a sacred text.

Near the conclusion of the Scrum Guide there is an 'End Note' that I find infuriating:
Scrum is free and offered in this Guide. Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
If anything at all varies from what is found in the Guide, we are not to call it 'Scrum.' I call shenanigans! Agile is about adaptability, among other things. Scrum is an Agile methodology that prioritizes teamwork to inspect and adapt. Teams adapt Scrum, in small and large ways, to fit their circumstances. Over time these changes might be adopted by other teams in other places, and even make their way into the Scrum Guide itself.

Scrum teams learn.

Finally, the Scrum Guide itself is made available under the Attribution-ShareAlike 4.0 International licence, which states:
You are free to:
Share — copy and redistribute the material in any medium or format
Adapt — remix, transform, and build upon the material
for any purpose, even commercially.
Someone  might argue that there's no conflict between the conditions of the license and the requirement that any variation not be called 'Scrum,' but that sounds like hokum to me. If you are a Scrum Master, Product Owner, and/or Scrum team, I suggest you try following the Scrum Guide to start (unless your company already has another standardized interpretation of Scrum it uses), and then inspect and adapt from there into what works for you. And yes, if you do so, it is still Scrum.

Monday, January 08, 2018

"That's Not Agile"

It grates on my ears every time someone says "That's not agile," even when they might be justified in saying so. It's said far too often and without much thought, often reflecting more of the bias and personal preferences of the person complaining than it does any violation of the spirit of Agile.

What is Agile? It boils down to the Manifesto For Agile Software Development, as worked out in 2001:

  • Individuals and Interactions over processes and tools
  • Working Software over comprehensive documentation
  • Customer Collaboration over contract negotiation
  • Responding to Change over following a plan
That is, while there is value in the items on the right, they value the items on the left more.

That's both simple and sufficiently vague to allow some room for interpretation. Sadly, I hear people calling any documentation at all, any handing down of deadlines, or any semblance of a project plan 'unAgile.' This is the sort of thing that gives Agile in general a bad reputation in certain circles, making life harder for the rest of us who aren't self-proclaimed guardians of Agile purity.

There are approaches to being Agile that are more specific, like Scrum and Kanban, but Agile itself is happily free of major constraints. It's about tendencies rather than following a code of law. Now, I have a bone to pick with people who are Scrum purists as well, but that's a topic for another day.

Tuesday, January 02, 2018

Waterfall in Scrum Clothing

It was painfully clear the people from the vendor wanted to please us when they started using Scrum terminology to describe what they were doing. It's just a shame that they were still doing waterfall.

Sitting across the table from them at the kickoff meeting, the vendor representatives laid out their schedule. They told us what to expect with each sprint, listing out deliverables and so forth. Aside from the fact that this was all projected out ahead of time and left in no way to their development team, the sprints themselves were of irregular lengths. There were two week, three week, and even five week sprints, in no perceptible order or pattern. Finally someone asked them why the sprints were different lengths, and a project manager told us that this was necessary because some of the work couldn't be made to fit into sprints of a single length.

At this point, let me make two things clear:

First, in Scrum, the product owner prioritizes the backlog and the team selects what they can work on based on that prioritization. This involves discussion and even negotiation between the two parties, mediated by the scrum master. Though the ultimate goal of the project can be defined, we won't know  for certain what goes into a particular sprint until the team actually commits to it.

Second, work can always be made to fit within a defined sprint length, whether that's one, two, or four weeks. Every so often I encounter a team that insists they're special snowflakes with work unlike any other team's, and so they can't organize along these lines. They've always been wrong. Additionally, it's a really bad idea to have sprints go longer than four weeks, as this detracts from the agility of the team. They have fewer opportunities to respond to change the longer the sprint goes.

When the project came to a close, we were all invited to participate in a 'retrospective.' I thought this was weird, given that we were the client and not the team members. I was right. It was weird. This was an old-fashioned post mortem with the client that was shoehorned into the general format of a retrospective.

Waterfall is not my preference, but I far prefer it being presented honestly and on its own terms rather than dressed up in Agile garb and paraded around. Rather than being impressed with the vendor's effort, I questioned their wisdom.

Tuesday, October 17, 2017

Sprint Mascots

Not everything about Scrum has to be serious. In fact, because of the Agile emphasis on 'Individuals and interactions over processes and tools,' I've personally found this mindset often fosters more 'fun' work environments than anything traditional project management can do. Aside from this natural Agile tendency towards a less dour situation, I also like to inject a little levity into the process wherever seems appropriate. One way I do this is with Sprint mascots.

Every scrum team I work with through an Agile transformation chooses a genre when we plan our first sprint. It can be absolutely anything, from a movie franchise to celestial bodies, and all points in between. When a team completes planning a sprint, I ask them if they have a mascot from whatever they have chose that they would like to use. This can work in different ways. 

One team I've worked with uses Star Wars, and so each sprint is named after a character from that franchise. There's a team member with an encyclopedic knowledge of the Star Wars universe, and he whimsically describes how this sprint that's planned reminds him of some particular (often but not always obscure) character. The team approves, and off they go. Another team decided to use cowboys and Westerns in general, opening up myriad possibilities from the worlds of TV and cinema, including animated characters like Yosemite Sam and historical figures like Billy the Kidd. With them there's a bit more discussion and no one designated 'namer.' It works out.

When possible, I play along with the team's choice.For example, there's a team I worked with a couple of years ago that decided to name their sprints after breakfast cereals. The first day of each new sprint I brought in a box of whatever type of cereal the team had chosen, and it was available for anyone who wanted some. During the two weeks of the sprint it sat on a shelf over the area where the team worked, like a flag flying.

What does this actually accomplish? I'm certain it doesn't do anything either way for velocity, but it certainly gives a small morale boost, and the teams I work with clearly enjoy it. Why make work dreary or treat people (aka 'resources) like machines? There's nothing wrong with a little fun, especially when Agile is involved.

Monday, October 16, 2017

Agile Reporting: In Defense of the Sprint Review Meeting

Once, in a project management role with a tech startup in NYC, I led the dev team into adopting Scrum. We had daily standups as well as sprint retrospective and planning meetings at the close of each sprint. A point of contention, though, was around ‘release notes.’

In standard waterfall development it is common to have release notes go out whenever a new product or an update to the product ships. This makes a great deal of sense given the amount of time that went into making the finishing product, with well-defined requirements from the outset. In Agile, however, the idea is to be…well…agile. When a sprint concludes there typically will not be a finished product, neatly wrapped up with a bow on top. What is delivered is a potentially shippable product increment.

Here’s a very rough outline of how an Agile approach should work, as I see it:
  • User stories are written, covering what is believed to be needed for the product. These follow the pattern of “As [user/role] I want [function, request, etc] so that [outcome].”
  • User stories are placed in a backlog, groomed by the product owner and prioritized.
  • At the sprint planning meeting, the scrum team reviews the backlog, providing story points or some other arbitrary measure of a user story’s effort (not time) and selecting out what items will go into the sprint backlog.
  • The scrum team formally commits to do the work required to complete what they have selected for the sprint backlog.
  • Development begins, and runs for however long the team has decided sprints should last (a week, two weeks, a month or perhaps more).
  • At the conclusion of the sprint, the team presents the work completed in a meeting open to any and all stakeholders. There is no formal powerpoint presentation, but rather a demonstration of the product increment. This is the sprint review.
  • After the sprint review, the team gathers for a retrospective and then a fresh sprint planning meeting.
The sprint review meeting is key to Agile success. The heart of Agile is ‘inspect and adapt,’ and it’s in the sprint review meeting that the scrum team can learn whether it is on the right track, per stakeholder evaluation, and also whether they should change course.
Consider two scenarios:
  1. The scrum team concludes a two-week sprint, gathers stakeholders and demos the product increment. The stakeholders notice some departures from what they had in mind. This could be due to a communication failure in the form of poorly-written or incomplete user stories or because the scrum team misinterpreted. All is not lost! It’s better they hear they are off-track now and make adjustments in the next sprint, than to have gone the waterfall route and possibly only found out they were mistaken when the product was ‘done.’
  2. The scrum team concludes a two week sprint, gathers stakeholders and demos the product increment. However, now that the stakeholders see it in practice they realize that it’s not quite going to serve their needs or interests. This could mean a few tweaks or an entirely new course based on their fresh evaluation. In response, user stories are written to serve this purpose and the team takes this new direction into sprint planning.
Release notes are all well and good, but of little practical value in a truly Agile organization. The sprint review meeting, however, can make all the difference.

Friday, October 13, 2017

From Minister to Project Manager (Part 2)

[Read Part 1 Here]

When I was asked about my ministry experience during the team interview for my first startup job, I didn’t miss a beat. The question was straightforward: “How do you feel your mission experience might help you at this job?” It was fair to ask, given that at that point the only roles since my time in ministry work were English teaching, office assistant in a law office, and enterprise customer service at AT&T. I told them that I knew how to organize work, projects and people. Further, I was accustomed to handling my own area and working independently, so I didn’t require a lot of supervision. In other words, I was a self-starter committed to seeing people succeed individually and in teams. It may sound like fluff, but it’s true and I stand by it.

There is something truly pastoral about project management, as it involves ‘shepherding’ a project through to completion, as well as taking care of the team that does the work. I wonder if perhaps much of the suspicion and even outright animosity that developers hold towards project managers can be boiled down a few professionals more focused on the project timeline and milestones than on the people and the work itself. Developers are artisans as well as (when at their best) engineers. What they need are people who can remove impediments to efforts and give them room and conditions to flourish.

That brings me to Agile.

While working as a web producer at that startup mentioned above I started to hear about ‘agile’ and ‘scrum.’ Asking around, one of the developers loaned me a copy of ‘Agile Software Development with Scrum.’ I had minimal project management experience at the time, but this was love at first sight. Talk of removing impediments and promoting self-organization of dev teams won me over.
In the following years I went on to learn to guide projects both through Waterfall and Agile processes, but what always prevailed was a team-centric, product-focused outlook. To me, my professional work as a project manager / scrum manager is somewhat of a representation of my ministerial background.

An additional angle to the relationship specifically between ministry and scrum is the existence of ‘ceremonies.’ Clergy are responsible for guiding people through ceremonies that mark significant moments in life, such as birth, coming of age, marriage and death. In a smaller and yet still significant way, the routine ceremonies of scrum (planning, daily stand-up, review/demo and retrospective) help the team understand and feel connected to the work. Ceremonies are a natural part of the human experience, and scrum makes good use of that reality.

For years after quitting full-time ministry I was very negative about having gotten an undergraduate degree in theological studies. Then a coworker — who happened to be an atheist — strongly disagreed with me and got me to see things differently. He told me that my Bachelor’s had helped me learn to think, and that ministry isn’t a bad thing at all if seen in terms of working to help others. Further, in the NYC tech scene it hardly matters what your major was, so long as you have a degree and can get the job done right.

As I said in a prior post, I’m no theologian. However, in the sense that I seek to help groups of people achieve goals and constantly do better, I suppose I’m still in ministry.

Thursday, October 12, 2017

From Minister to Project Manager (Part 1)

Sitting across from the gentleman in downtown Uberlândia, Brazil as he reviewed my résumé, I expected a standard line of questions. He’d ask about projects I’d worked on, whether or not I’d managed teams and to what extent I understand code in particular and the software development cycle in general. Instead, what came first out of his mouth instead was a statement: “So, you’re a theologian.”

That floored me. Although I hold a Bachelor’s degree in Ministry, the bulk of my professional life has been spent in software and website development. Rarely in New York City have I even been asked about the nature of my undergraduate study, something I suspect comes as much from indifference as a suspicion that it’s not okay in interviews to get too close to the topic of religion.
Having spent a few years following graduation in mission work and then serving a church in New Mexico, I became disillusioned with ministry and resigned. After moving my family to New Jersey I taught English as a second language for a year in a predominantly Brazilian and Hispanic neighborhood in Newark before taking a customer service role at AT&T (then called Cingular Wireless) servicing major business and government accounts.

Customer service in a major corporation prepared me, strangely enough, for life at a startup. A company called ZepInvest was looking for someone to do customer service and manage content curation full-time, and I applied. The experience I gained over the next few years was invaluable to my career. It was there, in close proximity with product people and developers, that I became a web producer. As is often the case, startup life requires people to wear many hats. While some fit better than others, the options were grow or get out. I grew.

When that company closed down operations in New York, I transitioned swiftly to Conde Nast, where after a year as a web producer I was promoted to project management and assigned to Wired. I worked with a fantastic team to bring that brand’s development team into order, and by the end of a year with them I was ready to hand over the job to a director of engineering on-location in San Francisco (the site lead and I had been working out of New York, so a lot of phone calls and a cross country trip or two were involved).

My next roles were at Scholastic and The Loop, both of which enriched and deepened my experience as a project manager, forcing me to think along product management lines as well as explore questions of product/market fit. In 2015 I was at PINCHme, and while that was a short-lived role, I had the pleasure of working with a solid team of developers and a level-headed product manager to organize along Agile lines and bring a complete site redesign to life within three months. Now, at Viacom as a Program Manager, I have lead multiple teams through Agile transformations and am working with others to effectively scale Agile for the enterprise.

In light of all that, it surprised me that the Brazilian man’s first comment to me was that I’m a ‘theologian.’ It turns out that in Brazil, people are pigeonholed based on whatever university degree they’ve obtained. If someone gets a degree in accounting, she will be considered an accountant no matter what, unless she goes for another degree or really makes a name for herself by some means in another field.

No, I am not a theologian. I’m at my best when I’m filling the roles of Scrum Master and Agile Coach. That, in fact, is where I believe my ministerial training and experience most comes to the forefront. More on that tomorrow.

Wednesday, October 11, 2017

Individual Velocity in Scrum

Early on in a brief stint as a project manager with a startup in New York, the product manager told me we needed to track individual velocities on the team. We had only just begun an Agile transformation, with me as the Scrum Master and her as the Product owner. She said it was just for our own tracking purposes, but having been told before by someone in senior management that he wanted to know which of the developers were 'slacking off,' I knew why she was really asking.

The short answer to a request for individual velocity tracking, in an Agile environment, is ‘no.’ This is actually a big no-no, for at least a couple of reasons.

First, story points (or whatever method is used to weigh effort on user stories) are not precise. A team might look at a story and call it a ‘5’ (using Fibonacci, considering ‘8’ the largest) when it turns out to be a ‘3.’ Another ‘5’ could turn out to be an ‘8’. In the first case, the developer could end up looking like a whiz. In the second, she would be a slacker.

Second, Agile is all about teamwork. The time rises or falls together. If one team member is not carrying her weight, the team needs to deal with it. Perhaps she’s experiencing personal problems, such as a death in the family. Maybe she could benefit from some pair programming. Then again, maybe she is chronically ineffective, in which case it the situation will have to be escalated to management. That should always be a last resort.

The team velocity, not individual velocity, tells the real story.