I loved this talk, and would encourage anyone who works in teams expected to ‘innovate’ to take 18 minutes to watch it. A couple of quotes from the talk that particularly spoke to me are copied below.
Bringing consensus and group based decision making to traditionally ‘top down’ organisations or people is hard. This talk will give anyone facing such a challenge a little food for thought, I’m sure.
What we know is, at the heart of innovation is a paradox. You have to unleash the talents and passions of many people and you have to harness them into a work that is actually useful. Innovation is a journey. It’s a type of collaborative problem solving, usually among people who have different expertise and different points of view.
Leadership is the secret sauce. But it’s a different kind of leadership, not the kind many of us think about when we think about great leadership. One of the leaders I met with early on said to me, “Linda, I don’t read books on leadership. All they do is make me feel bad.” (Laughter) “In the first chapter they say I’m supposed to create a vision. But if I’m trying to do something that’s truly new, I have no answers. I don’t know what direction we’re going in and I’m not even sure I know how to figure out how to get there.” For sure, there are times when visionary leadership is exactly what is needed.
But if we want to build organizations that can innovate time and again, we must recast our understanding of what leadership is about. Leading innovation is about creating the space where people are willing and able to do the hard work of innovative problem solving.
Zendesk has a nifty piece of functionality that automatically assigns a ticket to an agent when they change its status to Solved. It deals with the issues caused by the ease of being able to forget to do that manually. It’s also a massive time saver.
There are some kinds of tickets (eg. Twitter spam) that you might not want to solve one by one, but instead solve them quickly in bulk.
The combination of these two things causes an interesting problem: if someone later replies to the Tweet, the ticket is reopened and auto-assigned to the agent. We would rather any agent pick up that ticket, because nobody really handled it in the first place. Continuity of service isn’t important in that scenario, but speed of response is.
So, here’s how to set a trigger to stop this from happening.
Problem solved. All these kinds of tickets are now added to the general pool when when they appear.
Bringing agile ways of working to teams comprised entirely of people focused on business (ie. the non-tech folk) is a challenge. It’s notoriously hard to do, because the kind of work that’s undertaken isn’t easily shared, paired on, broken into sprint or sub-sprint length tasks. It’s not impossible, though. Here’s some of my experience (a work in progress).
Bringing agile ways of working to a team used to waterfall methodologies, reporting, and documentation will never happen overnight. Prepare to be very, very patient.
Understand the journey
Start by understanding what it is you want to achieve by bringing agile to your team. It’s not a magic pill that suddenly makes you more efficient, not by a long shot. Take a look at the things you aren’t doing well as a team, examine the reasons why that’s so, and then objectively evaluate whether or not practices from the world of agile delivery are even appropriate. They may not be, and certainly don’t assume that an ‘all or nothing’ approach will work.
What’s not so great? On joining a team there was a very clear structure (in terms of org chart) and clear reporting lines. Roles were well defined, but largely in silos. As a result collaboration wasn’t great, and nor was communication. Earphones were often in use throughout the day.
What’s the cause? Having a formal hierarchy and roles in silos makes it very difficult to collaborate. Visibility is poor, and so opportunities to contribute don’t exist.
What’s the agile journey? A full roll out of a formal agile methodology isn’t needed, but bits of one are useful.
Create visibility by employing some kind of information radiator (eg. JIRA). Create a space to interact by reviewing stories (eg. Backlog grooming). Create a collaborative environment by showcasing work and inviting discussion (eg. Monthly showcases).
Build understanding and buy-in
Once you have an idea of simple, actionable changes you can make to the way you work, the next thing to do is to start building support for those initiatives. Depending on where you are working, this may be somewhere between super-duper-easy and super-duper-hard to achieve, so here are my tips.
Start small. This is why I say that ‘all or nothing’ isn’t the best place to start. People like to be eased into things, for change to feel natural, and the best way to do that is to be focused on the smallest changes that will have the largest impact. Sticking with the example above, that’s why we’ve chosen to start with an information radiator.
Consider your audience. Different people in a team naturally take different roles. You have leaders, influencers, trusted confidants, followers, thinkers.. You name it, most teams will have people who fill one or more of these roles. Your job before you get going is to understand who to talk to first.
By and large, my tactic is to start with the influencers and their confidants. Win them over, and the rest will come along on the journey. The best way to do that is to share your idea in terms that state clearly what the benefit is to them personally. For example, if your influencer is a Project Manager you can sell the benefits of a communal information radiator as a way to make reporting and monitoring easier. Remember, you’re not aiming for an agile culture overnight, and so thinking in those terms (ie. reporting and control) are fine. They’ll change over time as you iterate over your plan.
Get the OK. Win over the person responsible for the team, get the go-ahead, and then share your thoughts with everyone on the team. That last step is key because it’s a subtle nod towards the kind of openness and visibility you’re trying to create.. it sets the tone.
Take baby steps
Implement your change, one at a time at first, and slowly. Take baby steps. At first you will find things difficult, but don’t be discouraged. The graph below, showing the Satir Change Model, and taken from this great post by ThoughtWorks on Adaptive Leadership, shows what you can expect.. in summary, after a change there is inevitably some resistance and difficulty before things significantly improve.
The idea of ‘reporting’ is disgusting and pervasive. I hate it.
That’s not to say that there isn’t a place for governance and oversight. I’m not about to argue against that. I’m talking about the idea of reporting driven development, the idea of a ‘status meeting’. I’m talking about the idea that you are being watched.
Now, if you’re on a project where your development, targets, and daily work are driven by reporting your status something is, in my humble opinion, wrong. It’s an indicator to me that you are concentrating decision making authority for too much to too few. It’s an indicator that your team feels ‘watched’. It tells me that at a fundamental level the communication on that project is broken.
If you’re using some kind of agile methodology or influence on your project (CD, XP, Scrum.. whatever) the chances are that you do some kind of stand up. The wording on the Teamreporter site looks like it’s targeting the stand up, with its “yesterday I..” / “today I will..” focus. Your stand up is not about reporting! It is, in fact, a valuable conversation! The whole point of the stand up is to keep everyone on the same page, informed, conversant, value and blocker focused, and avoid unnecessary work.
Your catch up meeting (whatever you want to call it other than ‘status meeting’) is all about the sharing. It’s about the personal conversation. It’s about people interacting with people, and building a stronger team as a result.
Move this conversation into email and what do you achieve? You reinforce the idea of a big brother watching, you allow people a reason to ignore it, you break down the positive communication channels that exist.
By all means, eliminate reporting as much as you can. Eliminate hierarchy and snooping eyes. Just choose the right target; a well conceived stand up isn’t the enemy here. Attitudes are, and in this regard I think Teamreporter has missed the mark.
As an aside, if you’re interested in this kind of thing, take a look at the excellent Agile Team Ceremonies post by Matt Copeland. The ‘bad smells’ sections are great.
I hate the phrase ‘Continuous Improvement’. It conjures in my mind the image of innovation days, innovation champions, written feedback, suggestion boxes. It makes me think of all of the organisations I’ve worked with who see that they are stagnating but fail to grasp the basic concept behind their stagnation: the desire to adapt and change is a state of mind, not a question of process rigour.
Go read the wikipedia entry on Kaizen and come back if you don’t know the term. That’s what I’m talking about. Everyone feeling a sense of ownership, everyone empowered to speak up to suggest improvements (big or small). If you are relying on enforced ‘innovation days’ then I fear the boat has sailed for you. Stop doing that, and think about it a little differently. Here are my suggestions for how you could go about making a big change with a slow burn (nb. slow burn = high buy in):
Continuous improvement isn’t a process you decide upon and implement, it’s a seed that you plant in your business and then let it grow. You should view this as a cultural journey, not a business process change.
Our project is lucky enough to have the holy trinity of analysis, namely dedicated business analysis, user research, and graphic design specialists. It’s amazing! Every two weeks we run user research sessions to gather feedback and try out new ideas, either with the working version of the application we’re building or with decent mockups.
Our user researcher goes. Our graphic designer goes. Heck, most times the majority of the team goes. I do not.
It’s not something I’ve really talked about here with people on the project, or publicised, but it came up today because I’ll be leaving the project soon and the Product Owner realised I hadn’t been to any of the sessions. So, here’s my thinking.
User research sessions are emotive, hot-house environments (from a project point of view). You learn an awful lot every time. The subject matter of our project is around redundancy and how people access the government service for help with redundancy pay and the like. As a result, it’s doubly emotive because the users are usually passionate. It’s probably triply emotive when you consider that many of the people we bring in have either gone through a redundancy or, I think once, going through one at the time.
That’s great because you build a real empathy for users, a sharp user focus, and you are confident that you’re testing your application with the most relevant demographics. All good so far.
The key word for me, though, is emotive. Whilst watching a user research session you’ll often hear people exclaim that ‘we have to do’ some thing, implement some change, change our focus. When everyone is present at a session that’s powerful, and it creates a group-think / reinforcement dynamic.
Quite simply, the reason I don’t go is because every project needs an advocate for the devil, a dissenting voice, an objective line of questioning. By not attending the sessions I gain an objectivity that is useful for challenging design or strategic decisions that have an emotive grounding in user research.
It’s right that the focus is the user, that we focus on user needs over perceived government needs, but it’s also right that we have rigour around that decision making process. When we change something based on user feedback and experimentation it needs to be robust.
And that, folks, is my reasoning. What’s your experience around user research, and how do you maintain objectivity around the features or enhancements that come out of that research?
Leena is ill/skiving this week, so it is my duty to blog the project chocolate experiment. The theme was caramel, and the competition was fierce.
A few notes before I share the winners and photos, folks:
And now, for the winners: