Sunday, June 28, 2015

What to call the Scrum Master of a Kanban Team?(Guest Post by Mike Longin)

Prateek and I recently presented an experience report at the Lean Kanban North American conference. And as we went through session, it became clear that one of our biggest challenges was helping our audience understand our deep-seated use of homegrown terminology, specifically surrounding job titles. For example, the title we use to refer to our Kanban “Scrum Masters” at Ultimate Software is “Iteration Manager,” or IM.

To be honest, this challenge isn’t new. Prateek and I often find ourselves using a few terms interchangeably – Iteration Manager (IM), Lead Process Engineer (LPE), and in some cases, Scrum Master. We’ve used these three titles to describe one position that has not changed that much since Ultimate Software’s original Scrum implementation in 2005.

In Essential Scrum, Ken Rubin defines the scrum master position like this:
“The Scrum Master helps everyone involved understand and embrace the Scrum values, principles, and practices. She acts as a coach, providing process leadership and helping the Scrum team and the rest of the organization develop their own high-performance, organization-specific Scrum approach.”

A key takeaway here is that a Scrum Master is the leader or the manager. It is their job to lead the team through the trials and tribulations of product development. And to that end, we empowered our Scrum Masters by making them responsible for the product the team is producing. If the need arose, the Scrum Master provided course corrections to keep not only the process, but also the product on point.

As we transitioned from Scrum to Kanban in 2008, we recognized that there was a need for a similar position – a leader who would empower the team to own the process and product they’d created. Similar to a Scrum Master, the leader would not have people management responsibilities. However, they would be responsible for the products and processes of their team. A new title was created—the Lead Process Engineer (LPE). The title emphasized the fact that our LPEs would make process management a major part of their day-to-day responsibilities. But the down side was that it under emphasized their responsibility for the team and its people.

In 2012 we made a process reversal, and roughly 25% of our teams returned back to a highly customized version of Scrum. But instead of calling team leaders Scrum Masters, we went with the term Iteration Manager (IM). These teams worked in parallel with our Kanban Lead Process Engineers, but we eventually adopted the IM title to cover all team leads, regardless of the process being used. Although the name itself was a bit of a misnomer as the job still derived its responsibilities from leadership qualities, not people management.  Thus the term “manager” is still a bit confusing to those outside the company. And once again, the title also highlighted the iteration (process) aspect and downplayed the people and product.

So what is a better name? After a bit of soul searching, I realized that whenever I spoke about my position to someone outside of the organization, I always used the term Team Lead. The more I thought about this, the more I realized that this term is the best fit for the position. While an agile team is self-empowered, I believe there is always a single person who should hold final responsibility. After all, when everyone is responsible, no one is responsible. That person is not a “master” of the team, but is instead the “lead.”

The Team Lead interfaces with outside parties and helps the team remove impediments. They may or may not lead internal team meetings like standups and retrospectives, but they are the person who ensures the team is making those ceremonies a part of their process. The lead is responsible for the team’s process, people, and product. And while they are not necessarily the team’s manager, they are empowered to help individual team members, and the team as a whole, succeed.

Personally, I also like the title because I believe it speaks more to the position itself than any of the previous names. Where Iteration Manager, Lead Process Engineer, and Scrum Master all highlight the process; Team Lead highlights what I believe is the most important aspect of the position – team. Now an interesting question could be whether Product Lead is a better title since that highlights the goal of any team, which is to ship a product.

Lead also speaks better to the position than Manager or Master – both of which imply the team works for the position itself rather than the position being one of responsibility. Team Lead highlights what makes this position the position it really is. You are neither a manager nor management. Instead, you are the team’s leader. You are responsible for leading them to success, which is just not conveyed with Scrum Master, Iteration Manager, or Lead Process Engineer.

Finally, for what it’s worth, I think the title also speaks more to the outside world. When we interface with customers, titles like Iteration Manager, Scrum Master, and Lead Process Engineer do not convey our personal responsibility to that customer. Team Lead, however, speaks to the responsibility we have to that specific customer while also helping the customer recognize who they are speaking to.

So what’s the next step? Obviously new business cards are in order (it may be time to buy stock in VistaPrint to keep up with the demand). Second is to get further buy-in from the Kanban community and Agile community as a whole. While it seems like a small thing, having consistent titles is an important part of helping a methodology mature. It also makes it easier for successful team leads in Kanban implementations to find work outside their company. Take a look on Monster and you’ll notice that there are 1000+ job openings for Scrum Masters. But to be honest, I have no idea what I would even search for to find a position at a company practicing Kanban.

So all of you Team Leads out there, what do you think? Is Team Lead the title you use (either publically or internally), or do you have something better? Let me know in the comments below, or you can reach me on Twitter at @mlongin.


Friday, June 5, 2015

South Florida Agile Summit Conference 2015 Recap and Review (Guest Post by John Johnson)


I had the opportunity to attend the annual South Florida Agile Transformation Summit, a local conference bringing together the South Florida Agile community to educate, discuss, and share everything Agile. Here’s my take on this year’s conference:
Scalability, responsiveness, and efficiency are hallmarks we‘ve all come to expect out of well-made modern software. Coincidentally, those three same characteristics—scalability, responsiveness, and efficiency—are now essential attributes we expect out of well-run modern software teams as well.
“But can it scale?”
Ken Rubin kicked off the annual Agile summit with his keynote talk on “Economically Sensible Scrum.” Fact: It’s now easier than ever to start (or convert to) an Agile project team. Pick up one of the thousands of books on Agile project management and get started with tried-and-true, battle-tested ways of getting an Agile team up and running. (Coincidentally, Ken Rubin’s book is the current best-selling Agile Project Management book on Amazon.)
But what about effectively managing an entire Agile organization? Sure, managing one functional Agile team is achievable and well-documented blueprints already exist, but what about a scalable, cohesive, and profitable software organization? This is where most Agile project management books end and, fortunately, where Ken’s keynote begins. The main theme of Ken’s keynote is that core Agile principles applied to individual teams is not enough for an entire organization to be successful—we need to step back and consider the Agile organization from an economic, macro point of view when making decisions.
Going beyond methodology to understand Agile through an economic lens allows organizations to make well-informed, cost-effective decisions. Agile principles are easy to misconstrue and take to extremes, unintentionally bogging down the organization with inefficiencies. Just because Agile states a team doesn’t have to do documentation/requirements up front doesn’t mean you should never do it. Just because you can change directions as a team quickly doesn’t mean it’s sensible to turn a project on a dime a few months before shipping.  We have to consider if a decision makes sense in an economic context within an organization.
The underlying assumption in Ken’s proposal is that there will always be waste in a project, but we need to focus on eliminating the most costly and economically damaging waste—and sometimes it can be hard to find the actual source of the most waste. Backing his argument with anecdotal examples, Ken suggested that in order to reach optimum efficiency within an Agile organization, decisions should be made with both Agile and economic principles in mind. Essentially, organizations should always strive to ultimately choose the most financially sound and business sensible option.
Some important takeaways I had from Ken’s keynote:
  • Reduce idle work, not idle workers
  • Reduce work-in-progress waste
  • Reduce overall cycle time with fast flow
  • Align project expectations with partners and sales
  • Keep high-performing teams together
  • Scale and organize multiple teams based on business sensibility and responsiveness, not dogma
Working in an Agile organization that has already implemented many of these suggested improvements, I absolutely agree with Ken. Having actively practiced these takeaways for quite some time, many now seem common sense and almost self-evident. Keeping cycle times low, for example, is nothing new or groundbreaking—this essentially translates into “keep your feedback loop short”, something organizations have been doing since being popularized by Toyota in 1953, or Six Sigma in 1986, and even more recently by Lean. Look at another example: reducing work-in-progress waste. Reducing excessive work-in-progress lowers multitasking and contact switching, which has been proven time over time to be hazardous to an employee’s productivity. Overall, Ken Rubin offered a very insightful look the evolution of Agile and offered useful and practical next steps for an Agile-practicing organization looking to improve.
Old dog, new tricks
Following Ken was a day packed full of presentations. Talks ranged from lectures on forecasting the future of Agile to workshops on establishing trust within a team and everything in between.

Mark Kilby from Rally Software discussing how to apply Agile techniques in a co-located/remote environment
A few trending/recurring topics I noted throughout the day:
  • Agile throughout an entire organization
  • Continuous deployment and continuous delivery
  • Data-driven decisions
Some of my favorite presentations of the conference were about using team-level or organization-level data to analyze and drive business and management decisions.
Prateek Singh, one of my colleagues, spearheaded the data-driven decision discussions, presenting to a standing-room-only audience about data-driven, objective team retrospectives. Prateek demonstrated how retrospectives, traditionally a subjective experience, can also be benefit from being objective by incorporating team data. Using tools like traditional burn-down charts or the more comprehensive Cumulative Flow Diagram (of which I’m personally a big supporter), and even scatterplots, we can analyze team data to generate talking points, reveal insight, and shed light on otherwise overlooked and hidden trends or problems. This data, paired with useful team discussion, can help facilitate and guide the team to make the proper changes in order to improve. As always, implement these team changes in small batches. Supported by real team data, Prateek clearly demonstrated that objective retrospectives are a must-have in any successful modern Agile team’s arsenal.

Prateek Singh presenting on the benefits of objective, data-driven retrospectives
Continuing the theme of converting an organization to agile, Danielle Lopez and Christine Rector led a great discussion about where the role of the business analyst fits in an agile environment. To demonstrate and reinforce the importance of the BA in Agile, Danielle and Christine also led a hands-on activity, having the audience break into small ‘development’ teams, passing out small Lego sets. Half of the groups were to build their Lego set using Waterfall development, and half of the teams were to build the given Lego set using Agile development. All Lego sets distributed were of the same Lego figure. Each group selected a person to be the BA of the group, to read instructions based on their development style. Waterfall BA’s were only allowed to show their team the final assembled Lego picture and answer questions, while the Agile BA’s were only  allowed to show the step-by-step instructions (much like an iterative Agile development cycle) and also answer questions. Can you guess which development style finished first? It shouldn’t come as a surprise: Every Agile team finished the Lego figure far before any Waterfall team finished, and with much greater accuracy. What was different between teams? How the business analyst interacted and was utilized during the teams’ ‘development’ process. This hands-on workshop really Danielle and Christine’s point home in a fun and tangible way – the BA is a crucial role within the Agile development process.

Danielle Lopez and Christine Rector discussing the role of the Business Analyst in an Agile Environment
Overall, this year’s Agile Transformation Summit provided some great lessons on effectively managing an Agile team and an Agile organization, and it offered an insightful look as to where the Agile community is headed. The South Florida Agile community continues to grow rapidly, and I’m excited to see where it will be at this point when I return next year.

John Johnson