Starbucks and Flow

Starbucks introduced their now much-used app in December 2014 in Portland. As they rolled it out to the rest of the country it has seen increasing adoption. In August Starbucks reported that 20% of their orders were paid via mobile payments and two thirds of those were placed through Mobile Order and Pay. The app has definitely been a hit and the adoption has probably brought a lot of customers back to being regulars(including myself).

The mobile order takes the waiting in line aspect of the Starbucks store out of the equation and knowing that my order will take about 10 minutes to be ready, helps me time my walk from the office to the local Starbucks as I wrap up the minor email-checking type activities. There is the added bonus of every 12 drink orders giving me a free reward drink when using the app. It is a great technology solution to a non-technical problem and Starbucks is explicitly and implicitly encouraging adoption of the app among its clients. Apart from the reward that I just mentioned, Starbucks also asked the baristas to treat mobile orders as expedites. These orders jump ahead of the drinks that have not yet been started, which means that everyone in the store that hasn't placed an order has dropped a spot back in line.

In the world of flow, expedites are almost always bad. They disrupt the system and cause delays to every other work item in progress. There are multiple repercussions to giving expedite requests priority, the major one being that you eventually get flooded with nothing but expedite requests. My assumption is that this is the exact effect that Starbucks was counting on. Whether intentionally(most likely) or not, Starbucks is counting on the ratio of the online orders to grow. There is a direct benefit to doing this for them. It is taking the entire ordering process out of the hands of the baristas, and outsourcing it to the customers. The baristas can now spend more time making the drinks rather than taking the orders.

In essence Starbucks is encouraging the exact opposite of the behaviour we coach teams. We tell teams expedites lead to unpredictable systems. Starbucks is trying to use expedites to add capacity to the system by outsourcing the ordering system. This seems to be leading to a more stable system. Lets run a quick simulation on a few scenarios here. The following assumptions stand for all simulations -

• There are about 40 orders placed per hour..
• It takes 30 seconds to take an order and process payment.
• It takes 2 minutes to prepare the drinks for an order.
• The simulation is run for 60 minutes.

Scenario 1 - No Mobile Orders, 1 employee taking orders, 1 employee making drinks.
This is the base simulation in a world where there are no Mobile orders. All payments and orders are done in person. The simulation saw 42 customers coming in and 15 of those orders successfully getting processed. Which means of all the customers that came in during the hour, less than half were successfully served at the end of the 60 minutes. The 15 customers spent an average of 1343 seconds, or about 22 minutes getting in and out of Starbucks. Based on our assumptions, that is 18 to 19 minutes more than the active ordering and drink making time.

Scenario 2 - 15% Mobile Orders, 1 employee taking orders, 1 employee making drinks.
This is similar to the numbers reported by Starbucks, in terms of percentage of orders coming in from mobile devices. With similar setup for arrival rates of orders, 26 customers had their drinks at the end of the hour. These customers spent an average of 490 seconds or close to 8 minutes getting in and out of Starbucks which is about 5 and a half minutes more than the active time.

Scenario 3 - No Mobile Orders, 1 employee taking orders, 2 employees making drinks.
What if we added capacity to the system in the form of an employee making drinks. With similar setup for arrival rates of orders, 34 customers had their drinks at the end of the hour. These customers spent an average of 326 seconds or close to 5 and a half minutes getting in and out of Starbucks which is about 3 minutes more than the active time.

	Scenario 1	Scenario 2	Scenario 3
Total Employees	2	2	3
Orders Completed	15	26	34
Average Order Cycle Time	22 mins	8 mins	5.5 mins
Average Wait Time	18.5 mins	5.5 mins	3 mins

The advantages of scenario 2 are numerous. The extension of the scenario, where 80% of the orders are mobile orders and the employee taking the orders spends more time making drinks than taking orders, actually come out similar to the scenario 3 results. In other words, by getting a good majority of their users to use the mobile app, Starbucks can have the employees do mostly drink making rather than order taking and double throughput(no. of orders satisfied) per hour. The simulation of this scenario showed a 4 minute net "cycle time" as well. Most of which would probably be spent by the user walking to the store rather than queuing up in the store.

These are results based on simulations and I would corroborate them with personal experience as well. I knew that the expedited nature(jumping the in-store line) of the app was working in my favour when I used it. I recently switched my phone and for the past week have not used the app and have found that the in-store line is taking less time that I remember as well. There could be multiple factors to this, but I am sure the adoption of the mobile app is a major contributor.

I am not sure if folks at Starbucks ran similar simulations before rolling out the app(I have a feeling they did), but they are definitely altering the flow of customer orders. The Starbucks app is not just an easy way to pay but a shift in user behaviour. The shift, on the surface, seems to violate some principals that we espouse while teaching flow, especially around expedites. The fact though is, these are not expedites, but reallocation of the work into the hands of the user from the hands of the employees.

The Grand Old Men Of Agile(...or what not to do when coaching)

It was a great pleasure to have attended Agile 2015. The sessions were mostly good, but my favourite part of the conference was "Open Jam" space. It was an open space where folks could propose topics and a small group of 4 to 6 people would discuss the subject around a small round table. The "Open Jam"s were more interactive than the sessions and was a great way to get to know folks and talk about real problems facing teams. I actually ended up attending more "Open Jam"s than sessions.

There was one open jam on Wednesday that stood out for me, but not in a good way. The session was proposed by a practitioner who was looking for games or a new way of doing retrospectives so that she could use to engage the one or two developers that think of retrospectives as a waste of time. As we learned later on in the conversation, she was a PA on the team and there were a couple of developers on her team that would rather be at their desks coding than be in a retrospective.

The collection at the table was illustrious. There were two experienced developers who just happened to be there and were looking for a space to pair program, they left pretty soon. The other two folks at the table were stalwarts of the agile development community. One of them is an original signatory of the Agile manifesto and the other's name shows up on the signatories page online (http://www.agilemanifesto.org/authors.html). In hindsight, I should have been more excited to see the two agile luminaries in action, but I was brought there by the topic of the open jam, and that was the focus for the moment.

The session was a little off right from the beginning. The PA looking for coaching had barely finished framing the problem that she had before she was hit with a series of questions, none, directly about the problem she was describing. "How involved is your product owner?", "What is the size of your team?", "How often do you release software?" were examples of the questions asked. While these might have indirect bearing on the issue at hand, the connection between the issue and the questions was never made clear to the practitioner who was being asked the questions. On the other hand, each of the answers she gave were treated as problems by themselves. I took direct issue with the experts pointing out that the team size of 20 people was an issue. We will come back to that in a bit.

Taking issue with the declaration that the team size was the biggest problem gave me the opportunity to interject and have two minutes to talk to her about the actual problem she was bringing up and we(her and I) figured out that the developers motivation, for example shipping code, needed to be talked about at the retrospective. If the retrospective was centered around things that are in the way of us shipping software and getting work done, the developer could be a lot more engaged and the retrospectives would be very beneficial for the team. At that point one of the experts agreed and started talking along the same lines. It was good to see some agreement around the table and it seemed we were making some progress.

Somehow the conversation came back to team size. I had mentioned that I have a 34 person team that delivers software on time and successfully exhibits the right team behaviours. This seemed highly extraordinary to the experts. They were a little taken aback that their 7 +/- 2 team size theory was being challenged. The lady asking the question had to leave to attend a session and I hope she got enough answers to make headway with the issue she is facing. Meanwhile, the rest of the table continued the team size discussion. I was asked how big should a team be if you were asked to build a team. Apparently my response of "it depends on the project or product to be built" was a "bullshit answer" according to the expert who signed the agile manifesto. I wonder if the same expert would choose a tech stack without knowing what product to build (I did not have the quickness of mind to ask this on the spot). I did explain to him that it was an inadequate question, as the composition of a team without a purpose is irrelevant and we need to define what the team is doing before deciding it's composition.

There was an interesting twist though. After I mentioned that at my company the average team size is 15 to 20 team members and we have a thriving and successful agile culture, they noticed that I worked at Ultimate Software and their demeanour seemed to change. They had both consulted at Ultimate about 8 years back and heaped praise on the culture at the company. They were gracious in their praise and conceded that the team sizes could work in that culture. The name of the CTO of my company was dropped in the process as well. They remembered how we used to hand out "Purple Cow" toys. These used to represent standing out in a crowd and being remarkable. At the end of the conversation, I took my leave and thanked the folks for the fun conversation.

That was the story(at least from my perspective) of the session. I had some obvious issues with it. The biggest issue was the body language and demeanor of the stalwarts towards the person looking for advice. One of them leaned back in an "I know better than you" position in his chair and spoke in what sounded to me like a condescending voice while asking follow up questions, and at times even asking them before person had answered the initial question. He also took obvious pleasure in landing zingers like "so you don't have a product owner" when they were told the product owner is not always present for the team. The other stalwart, the more famous one, from the agile manifesto, on the other hand, had the same condescending demeanor and was playing a game on his tablet throughout the conversation. This same expert did not even have the decency to look up from the game as he was asking or answering questions to the folks around the table. It was a bit shocking to say the least. He showed a lot more interest in the game than anything else for the course of the conversation.

It was just one instance, but if this is how these "Grand Old Men" of agile treat people and talk to individuals they should stay miles away from coaching people at close quarters. They have done great things in the past and have written books and papers that I and many of us have read. They have made practices that have changed the industry commonplace. They are great minds who have changed software development to a great extent, but in lieu of being able to treat folks who come to you with decency, they should probably stop coaching/consulting people and teams.

I had a great time at Agile 2015, met some great people, acquired some great ideas. The sessions, both scheduled talks and most open jams were great. There were some very empathetic coaches and leaders who presented great new ways of helping, inspiring and bringing teams together. It was one bad experience with a couple of grand old men of agile that was the "Purple Cow", but not in a good way. I hope I just caught them on a bad day at a bad time. If that was the case though, they should probably have stayed away from "trying" to provide help. Maybe they should leave that to the other empathetic, bright coaches who are passionate about helping teams and people achieve the best results without coming across as condescending or disinterested. I have to say I met quite a few of those at the conference this year.

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.

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

Quality Assurance Vs Testing

A couple of weeks back, we were doing training for a team. We talked at length about the benefits of team members who specialize in one discipline, moving around to help other disciplines. As I was explaining the role the test engineers play in this regard, Frank Vega(https://twitter.com/fxvega) mentioned something that put it a lot more succinctly. Frank, who was helping me out with the training mentioned that what we are talking about is the difference between testing and quality assurance. Let us draw the distinction more clearly.

Testing as defined by Wikipedia(yes, the source of all truths) is - Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test. Testing has the connotation that most or all the code for the piece of software being developed is already written. Piece of software might mean the entire project in a waterfall world or just one story in the agile world. In essence, the act of testing can begin only after the code has been written. There are many techniques that make this process effective. Test case design techniques like pairwise testing, equivalence classes, automated tests at different levels can make this activity a very profitable one. Many testers can even open up the code and write tests based on the code they see. White box testing is very effective at finding flaws and writing well guided test cases.

On the other hand Wikipedia defines Quality Assurance as a way of preventing mistakes or defects in manufactured products and avoiding problems when delivering solutions or services to customers. Quality assurance makes sure that quality is built into every artifact and every part of the process. Quality assurance begins from the writing of requirements and does not end till the shipping of the code. Reviewing/collaborating on requirements, code, test cases and automated tests are all activities that provide assurances at multiple levels that bugs are being avoided. Not saying that the actual execution of test cases is not a great source of quality assurance, but often we waste our best quality assurance minds on pure testing activities, rather than elicit their help in other quality assurance activities.

While testing is a product oriented activity, quality assurance is a process oriented activity. Testing is meant to find defects so that the problems can be resolved, while quality assurance is meant to prevent defects so that the problem never arises.

Similar to the concepts mentioned in the last post on this blog, QA folk have a much larger role to play than just testing code for the product. Most of us are familiar with the exponential increase in the cost of bugs the later it is in the development process. Getting your quality engineers to review and/or contribute to requirements could help better define stories and more often than not avoid bugs from being introduced even before any code is written. Getting QAs to sit with engineers when they are writing  code can help the developer understand the testing strategy and avoid writing the defects in the first place. Very often I have observed QAs be the bridge between the business language of the product analysts and the technical jargon of the software engineers.

This is very different from the traditional perspectives of "testers should test". How many times have we discovered that the requirements were written with assumptions that were invalid?  Having a QA review these even before the coding for a story started would have not only prevented the defect/rework from being introduced, but would also have prevented context switching for the devs and the analysts who might have moved on to the next story by this time. I am in no way suggesting that actually testing the coded piece of software is a useless activity. What I am suggesting, is that if all your QA folks are doing is writing and executing test case and automation, that is a waste of their talent.

There is still specialization to be craved in the discipline of developing automated test suites. You still need the more technical type of tester that is great at developing test suites that test the product well and prevent regression defects from being introduced by future stories. These folks can still review requirements, open up the code to develop test strategies and most importantly they can fix the defects that they find without ever sending the story back to the engineer(s) that worked on the story. Once again, preventing context switching and keeping the flow of stories going. The test engineers in this case provide Quality Assurance by being a lot more involved in the coding of the product than in the writing of the requirements.

What about the other roles on the team and their contribution to quality assurance? Product Analysts can and should help test stories as much as testers should help review/write requirements. Engineers should be involved in activities like code reviews, writing unit tests, developing other automation test suites and using their skills in the best possible ways to ensure that a quality product is being produced. The engineers sometimes have the best handle at assuring and testing quality as far as performance, deployment and security concerns go. They might be able to contribute to, requirements, code and test creation, especially in these disciplines.

None of this is revolutionary, we have always asked our teams to produce the highest quality products possible. The problem is that we have tried to do this via a heavy emphasis on testing our products rather than performing quality assurance activities on our products. I feel very lucky to work with some great quality assurance folks on my team alongside product analysts and developers who do their part in ensuring that they have built quality into the product rather than throwing things over the wall at the "tester" and making it their problem.

Not My Job And The New Definition Of The Superstar

Recently, I attended a training course in "Fierce Conversations". The course is based on the book by by Susan Scott that bears the same name. A very worthwhile course for anyone managing and/or leading a team. There was a lot to learn about the different types of conversations and how to go about having them in order to achieve the best results. The conversations under the coaching and delegation sections were specifically of great interest to me.

As a part of the course, we had to identify our trigger words. Words that make us get upset when having a conversation with someone. Beyond identifying these words, we were asked to pair up, share our trigger words with our partner and then use them with each other in conversation. My partner got through almost our entire conversation without reacting, but his last trigger word almost made him flinch. When it was my turn, I found out how much my trigger words have changed since I started working with teams that are trying to embrace Kanban and flow. I always thought the trigger word that affected me the most was "Calm Down", but I quickly discovered that the phrase "That is not my job" evokes a stronger reaction.

"Not my job" is the enemy of flow. What it means is that you are more interested in living in your box and working on what is your area of expertise rather than helping the team out where the flow of work is getting interrupted. This means programmers helping out the QAs, if the testers are getting backed up. This means QAs helping out the BAs if there is not a lot to test, but requirement definition is moving slowly. People moving around till everyone becomes a utility player who can plug and play in any area is, in my opinion, the future of teams.



This does not mean that we completely get rid of specialization. You will have folks who are primarily developers and those that are primarily UX designers and those that are primarily QA, but everyone on the team picks up skills in every other area. This means that resources can be moved around to free up any blockages that might be propping up in the team's flow. If an individual works in only one discipline, they are great at what they do. These same folks are rewarded very well for being good at the one discipline they have, which in turn leads to creation of a certain type of Superstar. Unfortunately this definition of a Superstar, while great for a team working in a waterfall model, is counterproductive to a flow-centered agile team. It seems that a lot of organizations have moved to being agile shops, but still reward waterfall Superstars.

What we need is a new definition of the Superstar. The superstar in a flow/agile world is not a master of just one discipline but an expert or almost expert in multiple disciplines. An amalgamation of multiple skills that can help the team regardless of what specialization the team needs help in. The new superstar is not a tester, an analyst or a programmer, he/she is just a developer. A great one at that. One that can help out the team to effectively maintain flow and remove blockages. A Superstar who not only helps the team finish work, but also pairs with every other team member to help them learn and to learn from them. I have been lucky to work with a few individuals that have been Superstars and the team is just rocking and rolling when they are in stride. Rewarding this behaviour and encouraging it is the key to making sure that it becomes more prevalent.

Think of it as a video game where your character's stats determine it's effectiveness. Lets say our players(developers) have three types of statistics - Analysis, Programming and Testing. Now imagine a player whose stats are along the lines of Analysis = 6/10, Programming = 7.5/10, Testing = 7/10. For me, this individual is clearly more valuable than the Superstar from the Waterfall era. They can help the team in the majority of the work the team deals with in all respects. If the business analysts are stuck then our all-rounder can help get some stories ready for the team. If the developers are stuck and the testers are idle, the all-rounder can code some stories and make them available for testing.

The stats of a waterfall era superstar would look more alone the lines of Analysis = 1/10, Programming = 9.5/10, Testing = 2/10. This person can code a lot of stuff, which can lead to a backlog in testing, but cannot help remove that backlog. This can make it hard for the team to achieve the ideal flow efficiency.  These experts are not necessarily all bad news. Experts are great for guidance and knowledge transfer. Pairing them with individuals who need their skills further developed, might be the best way to get those two things accomplished. Experts can be very bad for the team as they can create knowledge and skill silos. The more we let them work in their ares of expertise by themselves, the deeper those silos get. The trick is to not reward them for their individual contributions in their areas of expertise but for how much they have been able to bring the team's average statistic in their area of expertise up.

The idea is for everyone on the team to hone their all-round skills. There is a great amount of flexibility, agility and flow efficiency to be gained here. Some of us are better at gathering requirements, others at programming and others at testing. We all have abilities in every other discipline and in an ideal team, we will all be at level 10 in all disciplines. That might be a pipe dream, but, just like everything else we can strive for the ideal. As long as we keep raising our levels in all disciplines, we are making progress towards the new agile Superstars.

It all starts with hiring the right people and training the existing ones. Your job postings should look for developers who work on teams, rather than BAs or Programmers or QAs. Hire people who love to learn and who love to be involved in all aspects of the story. Train, encourage and reward your existing team for cross functional expertise and dissuade silos. It is time we start hiring team players and not superstars. People with the urge to grow, and the desire to help everyone else grow. There will always be the very few who would go into the expert role, but those should also be team players who are willing to teach.

The old definition of the Superstar needs to be removed from the books. It belongs in the waterfall era where churning out work in just your discipline was the key.  We need the new definition of the superstar to become the norm. Reward people for their versatility and their learning and teaching abilities. It is time for us to move our personnel and our hiring practices to the next stage, where we have moved our teams. We need to hire people that increase the agility and cross functionality of the team, not those that might hinder it. Hire, encourage and create the Superstars of the agile era teams.

When Process Junkies Are Parents - Personal Kanban

It all started a fine Thursday evening when my wife and I got home. Our daughter was in trouble with her grades and was falling behind on her schoolwork. We sat down and started reviewing where she stood with everything and what problems she was having and quickly figured out the issues. She had too many things going on at the same time. She was not sure about what to prioritize. There was no certainty whether the items she believed to be done, were actually completed.

Earlier in the day there was a Kanban training for a team that I was helping conduct and a lot of the issues/solutions we were talking about in the training seemed to be similar to the ones that we were talking about with our daughter. My wife and I, both running Kanban teams, we had an obvious solution to all problems - "You need a Kanban board". The following was the result.

Miranda(my daughter) seems to love it. Her WIP limit on the Doing column is 2. This helps her concentrate on fewer items at a time and also helps her pull the most urgent ones forward. Everything goes through a parent sign-off before it is considered closed. This helps ensure that everything that we consider done has been reviewed for completeness and quality. Miranda gets a constant visualization of her progress on tasks and so do we. There is no mis-communication on whether a task was finished or not.

Watching Miranda achieve productivity with her board made me think of my own problems with prioritization of work items. I have numerous things pushed onto my backlog and I try to get too many of them done at the same time. The solution again was obvious - I needed my own board. I would love a physical board, but since I work on items both at the office and at work, that was not going to work. Physical boards are great information radiators(exactly what Miranda needed), but are just too cumbersome to carry around if you need them in two places. So, I found an app that worked with my favourite browser, Chrome - Kanban-chi and have been using it since. As you can see this post is, as of right now in my Doing column.

I have to say, it has come the full circle. From the things I have learned working with my team to what Dan Vacanti,  Mike Longin and myself talk about in Kanban training to the working needs of my daughter back to how I can best manage my work. Sometimes, it seems, we know the answers, it just takes questions that are closer to home to help see the right context. I am sure I will still have some issues managing flow on my work items, but making consistent progress should not be a problem. I recommend personal Kanban to anyone who is willing to give it a try. If it can work for a 20-things-thrown-at-me-a-day-middle-manager and for a school going teenager, it can work for anybody. Also having a Unicorn and a couple of Pandas(I think thats what they are) drawn on your board helps as well.