Pages

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.