Tagged: team building

RAPID Agile: Focus on Product and Customer by mixing Scrum and Kanban – ScrumBan

We are usually torn between building more “product” or satisfying the “customer”.

Prioritize Customer (maintaining product)
Fix and release to save the world

Prioritize Product (building more product)
Plan and build to a schedule

When you focus on product, you have a certain “amount” of product that needs to be built within a sprint (time box); you can plan for fixes by leaving some room for the defect backlog, but features come first – then come fixes, and the work is usually fixed where people know what they are working on for the sprint. In this scenario most will usually package after the sprint is over (test and release)

When you focus on customer, you have to fix and get the fix out the door ASAP. Priority is given to the most critical fix and/or customer and things will be packaged (test and release) as soon as appropriate and/or possible.

Some solve this by having a sustaining engineering team, but who really wants to only fix defects?; others use a mix of cross-functional or functional teams and adjust as needed, but this can be disruptive.

If you chose to “adjust as needed” (be agile) you will introduce some chaos every now and then but this can be minimized by having “plan of action”. How you adjust as needed and what type of “plan of action” you need also depends on what type of process you follow and what your focus is; is your culture focused on product? or is your culture focused on the customer? Depending on whom you ask (their role) within an organization, you may get different answers.

If you follow “Scrum” then your work queue is mostly “push” defined, where work is planned and pushed into a sprint/iteration before its worked on.

scrum

If you follow “Kanban” then your work queue is mostly “pull” defined, where work is pulled and worked on.

kanban

In an ideal world, one would have a process that allows the focus on both, the product and the customer. A process that allows you to “build what you say you will build” but also allow you to focus on “what is important right now”; such a process would mix Scrum and Kanban, giving you, ScumBan. The idea of a Scrumban is not new; there are books and many talks/posts regarding this. How Scrum and Kanban are merged together depend on the person who is cross-breeding the processes and what problem(s) they are trying to solve; I named my implementation “RAPID” for “Real-time Actionable Prioritized Individual Delivery”.

In my next post around RAPID, I will go over some examples that helped define the how and why behind RAPID and how it would be used in a team that wants to focus on both, the product and the customer.

Advertisement

Building high performing teams by showing your employees how they can do better

This topic builds upon the previous “Building high performing teams by telling your employees they suck” (its not as simple as telling someone “you suck”); the emphasis really comes down to communication (showing) and attributes (why) they are not performing.

I learnt very quickly in my career that quality metrics do not lie and can easily convince to win an argument. I also learnt that pictures and diagrams help me explain (and understand) things much quicker than words alone. This is why, whenever I have had to prove something to myself, or explain a point; I have turned to metrics and diagrams.

So lets first cover some basics

Many companies do an “annual review” dance; some do it twice a year, some don’t even do it (we wont talk about them)…  and during this review, the expectation or assumption is that the person being reviewed has been working towards their goals that were defined the year prior; or that if goals had changed, then things would have been appropriately documented to reflect that change…. Truth is.. we do not have time for this; especially when you are in a high demand team where priorities change on you all the time. However; if you have been actively carrying out your 1-on-1‘s and have been using it to develop the person/your team and have some sort of career path or individual development plan in place; you may be well prepared for this annual review – Great for you!

Some lucky ones get an annual, semi-annual (or sooner) 360 review; I believe this provides more value than an annual review because it lets you hook into career development much sooner and/or it will give you insights to how you efforts are perceived by a larger audience who may be working with you on much closer day-to-day basis; this can one stay on top of their game if its done in short enough period as it is a great motivator. Managers can then review the trend over time and see how one is progressing to give a more accurate review.

At the end of the day, with all these reviews, coaching, development plans, etc. what we are really trying to do is grow people (or remove the ones that wont grow), make sure they perform and build teams that work well.

High-performing teams don’t just happen, they are made.

It is my opinion that in order to build high performing teams that work well; you have to instil a culture around “working well”. The annual, semi-annual, etc reviews really need to tie into a day-to-day type of thing; it may be seen as a lot of work (initially true), but just like good and frequent maintenance goes a long way, so does this.

To recap; what I have just stated is that we should focus on reviewing everyone on more frequent basis; something that ties into the day-to-day and can be captured daily or weekly… or best, if it can be captured adhoc as long as its captured within some frequent frequency. We would of course want this to be documentable, repeatable, measurable and actionable… we would want a process.

So, if this all has not added up yet, we want quality metrics that will provide diagrams/results based on process that can be used to communicate performance.

Every couple of weeks; I will ask my leads “without any thought into this, respond to my email and stack-rank your team”; or I will ask “If you had to do a project, who are the 3 people, in order of preference, you would pick”. Then there will be the “who is the most active volunteer” or “who is the least to volunteer”…  While these questions lead to answers that I plugin to my brain somewhere and maintain on spread sheets… they do not translate to quality metrics because they are not standardized enough… nor really repeatable.. (and probably other reasons as well). Another flaw with my method of capturing metrics is that it doesn’t allow “everyone”offer an opinion; only the ones I happen to ask or interact with that day. So while I may be able to “wing-it” and come up with diagrams based on some metrics… we need to focus on improving the quality of these metrics.

Quality Metrics

What does “team work” mean to you? What are the attributes of a team player? What type of people do you want to work with? or what type of people do you want working for you?

Here are some interesting data points that one can use a 1-5 scale to rate someone on (in no particular order)

  • Reliability
  • Constructive communicator
  • Active listener
  • Problem solver
  • Active participant
  • Shares solution/ideas
  • Volunteers assistance
  • Flexible
  • Customer focused
  • Respectful

In addition to defining the data points; you want to make sure that everyone has an opportunity to provide this data on “any one” without a need for self-identification (remain anonymous) and you will want some way of reminding people to go back and update (or resubmit) data at some frequency.

Creating a process around capturing these metrics and emphasizing the need to submit feedback sends a strong message to your team(s) that this is important.

Communication

Once you have reviewed, tweaked and confirmed (adhoc charts) that you are capturing data that is meaningful; its time your shared the results with the team (where appropriate) and with individuals (as needed).

The diagram below is probably more for your own viewing (rather than sharing with the team)

ImageThis diagram identifies the low and high scorers (averages of combined attributes); and you can see from above, Employee 4 is a low scorer.. (bottom of stack rank)

You may want to dive deeper into this, and you will see

Image

Where everyone lies based on attribute; is there a deviation for anyone? or does everyone score low in a specific category?

Again, from the above two it seems like Employee 4 isn’t at par with the rest.

Communicate

Communicate how/why/where they are not performing… a picture says a lot more than words, see below:

Image

This chart can be used in a 1-on-1 with Employee 4 to go over their specific performance; and can be tied in with what the “average employee” scores (which is just avg score per attribute), see image below

Image

This image that compares employee 4 to the average employee gives the employee actionable data that is backed by metrics. They can then use this information to focus improvement efforts.

Conclusion

So while its easy to focus on the literal words used. The goal should never be to tell someone that they suck (and stop at that); it should be to help drive change, development and improvement in someone by clearly communicating areas they need to focus on so that you can build a high performing team.