Agendashift as coaching framework

[This is the second of a three-part series. Start from the beginning: Lean-Agile transformation as Lean-Agile process]

What with last week’s London workshop (sold out!) and work on the new book I’ve got a bit behind my usual blogging schedule. Sorry about that! Every cloud though – here’s Agendashift partner Andrea Chiou debriefing (in Slack) her appearance this week at the Agile NOVA meetup in Washington, DC:

I said, using this style of interview, you can get managers in a room learning about each other’s vision for their most pressing problems, and in doing so you can then see where there is energy, as well as where there are solutions already inherently existing within the org

And:

This differs from almost every other Agile transformation approach I know, except one (I mentioned Open Space Agility). And the reason it works is because it is values-based, and based on mutual exploration and dialogue with managers/sponsors.

I might add here that Agendashift is also about exploration and agreement with participants (not just managers and sponsors), but Andrea does a great job of explaining how Agendashift helps facilitate those early conversations.

Especially in the guise of the Agendashift facilitator day, you can view the Agendashift workshop as a demonstration of three things:

  1. The power of a values-based and outcome-centric approach
  2. How the different techniques we use integrate so pleasingly
  3. An end-to-end transformation process that mirrors (and even exemplifies) a Lean-Agile delivery process.

Part 1 in this series expanded on point 3. Today, we’ll again review the five sections of the workshop, this time as a possible structure for a coaching engagement:

  1. Discovery: Identifying the strategic goals and needs that any coaching must support, setting the right tone in terms of ambition without losing sight of where the real challenges and opportunities lie
  2. Exploration: With or without the aid of the Agendashift assessment, exploring key areas of opportunity in more detail, identifying obstacles, and from those generating a set of outcomes that represent the scope, objectives, and priorities of the engagement
  3. Mapping: Understanding the challenge in enough breadth to be sure of not missing anything important, and keeping the coaching process fed with fresh and important challenges to investigate
  4. Elaboration: Generating, framing, and develop actions
  5. Operation: Ensuring follow-through, maintaining appropriate transparency, accountability, and feedback in the relationship

Just as we discussed in the previous post, this isn’t a completely linear process, in fact much of this needs to happen on a frequent or ongoing basis. There are however some key conversations that do need to be had, and the earlier in the process, the better. A coaching engagement that stands on a platform of agreed needs, scope, and level of ambition is surely healthier than one based on the offer of technical help or of facilitating a process whose goals no-one is able to articulate.

The tools we use and demonstrate through workshops will be used more informally and naturalistically in a coaching context, but they’re still valuable. All the more so, some of them! What coach wouldn’t want to be able to ‘flip’ obstacles into outcomes, identify the drivers behind pet solutions (and thereby open up the possibility of alternative solutions), or turn the vague into something actionable? These are very teachable skills. So too are the highly reusable skills of framing hypotheses and developing actions. Many coaches will find what Agendashift says about organisational design interesting too.

Coming up in the next few weeks are opportunities to experience this for yourself, with events in Hamburg (Feb 9th & 10th), Manchester (March 23rd), Edinburgh (April 6th), and Oslo (April 21st). Don’t see one near you? Get in touch and we’ll see what we can arrange together.

This was the second of three related posts (posts 3 coming soon):

  1. Lean-Agile transformation as Lean-Agile process
  2. Agendashift as coaching framework
  3. Agendashift as Good Strategy

Agendashift-cover-thumb
Blog: Monthly roundups | Classic posts

Links: 
Home | Partner programme | Resources | ContactMike
Community: Slack | LinkedIn group | Twitter

Lean-Agile transformation as Lean-Agile process

[Update: Section/chapter 2 previously named Analysis is now Exploration. Thanks to Mike Leber for the suggestion made at last week’s Agendashift facilitator day in London. 1. Discovery, 2. Exploration, 3. Mapping – that’s a nice progression! Some edits made to reflect this change.]

Did I mention that I’m writing another book? Writing begins in earnest next week, and the wait is killing me! Nearly three years after Kanban from the Inside, I again feel the compulsion. I have to do this!

The new book’s first five chapters mirror the five main sections of the Agendashift transformation mapping workshop:

  1. Discovery: Identifying strategic objectives, obstacles, outcomes, and change strategies
  2. Exploration: Debriefing your Agendashift values-based delivery assessment, prioritising opportunities, and agreeing scope
  3. Mapping: Building a transformation plan
  4. Elaboration: Generating, framing, and developing actions
  5. Operation: Organising for continuous transformation

If you’re anything like me, you might thinking “Plenty of plausible-sounding words there, but what makes the process Lean, Agile, or Lean-Agile?” It’s a fair question – there are enough linear, top down, cookie-cutter, imposed, consultant-knows-best, and resistance-trumping models out there and we surely don’t need another one! Can we instead demonstrate collaboration, iteration, flow, pull, feedback and the rest?

There’s an old Lean trick that I’ll be employing in chapter 5: review the process backwards, from finish to start, from life at the operational sharp end and back to the fuzzy front end. Here’s a preview, and it describes a process for organisational transformation that with just a few substitutions could easily describe a Lean-Agile process in the product or service space.

5. Operation

We meet frequently to review progress on the changes we have in progress and to share what insights we’ve gathered along the way. We’re validating the impact of our most advanced experiments to help us decide whether or not to adopt them formally. Some of our other experiments haven’t reached that stage yet – we’re still testing changes for their usability (there’s no point in endorsing changes that won’t stick). Still further upstream we keep a small backlog of prioritised and well-understood changes to work on as soon as capacity permits.

4. Elaboration

We’re careful not specify changes until we’re close to needing that level of detail – this isn’t big design up front (BDUF) but a just-in-time (JIT) process. Leaving it until the last responsible moment gives us the opportunity to incorporate feedback from previous experiments (successful changes or otherwise) and to take into account recent environmental changes outside our sphere of control.

Where appropriate (which is much of the time) we use the language of Lean Startup and A3 to frame and develop our actions. We take the outcomes that are the main units of currency of the transformation map and from them form hypotheses, identify who should to be involved in the change (to a significant extent we’re our own customers here, but therein lies a trap), design pilot experiments to test our assumptions, and so on.

3. Mapping

There’s much still be achieved, and it’s important to keep our ideas organised. Call it a planning tool if you like, we use a transformation map, highly analogous to a story map, except that the elements being organised aren’t features, user stories or job stories, but the outcomes we’d like to achieve through our transformation.

[Aside: The analogy is strong – the ‘so that…‘ elements of user stories and job stories are outcomes too of course.]

The categories under which outcomes are organised may describe the stages in a transformation journey or simply identify high level themes; sometimes one evolves into the other. This organisation comes under periodic review as we step back from the day-to-day and reflect on our overall progress.

We prioritise within categories before looking across categories and deciding on what we will work on next. In setting priorities overall, we may choose to give special emphasis to a particular category for a while, or decide instead that it’s better to choose a minimal set of complementary changes from across the board.

2. Exploration

Exploration keeps the transformation map both based in reality and connected with the vision, the output from Discovery. What do we know? What can we find out? What seems to be important? Who should we talk to? Where are the most promising opportunities? What’s our scope?

With Agendashift, exploration is a generative process. Informed by the results from the assessment tool, we collaborate on identifying opportunities and their respective obstacles, then ‘flipping’ those obstacles into the outcomes that will become either the work items or the organising themes on our transformation map.

We do enough of this up front to prime the pump and to get a good sense of what it is we’re really dealing with. We revisit it periodically; as our transformation progresses, so too does our understanding of what’s urgent, what’s possible, and where we think we’re headed.

1. Discovery

What would it be like if everyone were able to work at their best, individually, within teams, and across teams? What if we could have the right conversations between the right people always happening at just the right time? What if everyone always got what what we needed at just the right time too?

Why don’t we have that now? What obstacles lie in the way of achieving that? Can we go from all of that to a set of goals? What kinds of delivery approaches will be appropriate for the kinds of outcomes we seek? Who do we need to engage in the process?

This was the first of three related posts (post 3 coming soon):

  1. Lean-Agile transformation as Lean-Agile process
  2. Agendashift as coaching framework
  3. Agendashift as Good Strategy

If you’re a Lean-Agile practitioner and can see yourself using these tools, check out our partner programme. If you’re a sponsor of change and think this might work for you, check out our partner directory. In either case, check out our events calendar for a public workshop near you. If you don’t see one or you’d like one internally, get in touch.


Agendashift-cover-thumb
Blog: Monthly roundups | Classic posts

Links: 
Home | Partner programme | Resources | ContactMike
Community: Slack | LinkedIn group | Twitter

Three ways to get 2017 off to a flying start

1. An Agendashift-based coaching conversation: 60-120 minutes exploring the scope and goals of your Lean-Agile transformation, identifying key organisational objectives, obstacles, and outcomes. Take a mini or full-sized Agendashift assessment on your own as prework or as the focus for conversation.

2. A Transformation Mapping workshop: If you’re an internal sponsor, let us help you engage your colleagues in the transformation process, agreeing scope together, debriefing your survey, generating an outline plan, beginning to dig into the detail, getting yourselves organised for success. If you’re a practitioner, check out our partner programme – you could soon be using the all Agendashift tools and workshop materials yourself!

3. A longer engagement: Get regular support on site or remotely from an experienced practitioner who has been on journeys like this before, structured to give you the right combination of strategic advice, training, and hands-on coaching.

You can see these as a progression: each step a low-risk way to see what a bigger commitment might look like. The modes of delivery can differ, but the underlying models remain the same – always humane (respectful of where people are today), participatory (engaging people in the process from the outset), and refreshingly non-prescriptive.

Could Agendashift be just what you need? If you think it might, get in touch with us directly or find a partner near you.

Here’s to an exciting 2017

In case you missed it: 2016’s best bits. Not that we’re resting on our Christmas laurels!

Next week, work begins in earnest on a new book (my second), working title “Agendashift: Lean-Agile transformation for everyone”. I can’t wait to get started! Meanwhile, keep an eye out for a new series of blog posts:

  1. Agendashift as Agile process
  2. Agendashift as coaching framework
  3. Agendashift as good strategy

Our events calendar now shows Agendashift facilitator days happening every month well into 2017. These 1-day workshops are a great way for practitioners and potential sponsors to experience the Transformation Mapping workshop in a learning environment.

The calendar is somewhat UK-centric at present but we are busy fixing that. Listed already are events planned in Hamburg in February (a 2-day event in which Agendashift combines with Okaloa’s Flowlab) and Oslo on April; thank you Susanne and Thorbjørn for hosting these. There are more like this in the pipeline, and get in touch if you’d like to host an event in your city.

Happy New Year!
Mike


Agendashift-cover-thumb
Blog: Monthly roundups | Classic posts

Links: 
Home | Partner programme | Resources | ContactMike
Community: Slack | LinkedIn group | Twitter

Agendashift December roundup, 2016’s best bits

It’s the last Agendashift roundup of the 2016, and what a year! For this one I’ve simply organised our most popular posts into some semblance of (reverse) order.

Leadership

I’ve written and spoken quite a bit on leadership this year. Agendashift is all about Lean-Agile transformation, and you’re not going to see significant change without leadership. I’ve also revisited Greenleaf’s Servant Leadership model, noting that it’s something much more powerful than just “serve the team”. If only he were read more widely, including in Agile circles…

Needs

If you’re ok with mediocrity, keep on delivering “requirements”. If you want to do better than that, get into “needs”. And no, just because job stories illustrate this point very well, don’t take this as a gratuitous attack on user stories!

Lean-Agile

This popular post helps to explain why purely team-centric approaches can get you only so far.

Agendashift

I hope it didn’t escape your notice that Agendashift is now live, with an integrated online/offline product and an impressive array of signed-up partners (awesome folks all)!

While we’re here, I must mention our Slack community. It’s up there with the product launch, one of the most gratifying things I’ve had the privilege to be involved in. Request your invite here if you’re not a member already. As described only today (and not by me):

The Agendashift Slack is developing to be one of best sources of high quality discussion and learning now

And last week, about the programme as whole:

I’m so glad to be part of this!

Our LinkedIn group recently passed 500 members also. It’s not hard to keep going when you receive this kind of encouragement 🙂

Hypothesis-driven change

In my workshops and training I like to observe that Lean Startup – a decidedly 21st century approach to product development – borrows heavily from 20th century process improvement. And the favour is easily returned: if you’re working on improvement, why not use Lean Startup’s 21st century language? With a sprinkling of complexity-awareness thrown in (more on that later) and A3 (Toyota), it works great.

Note that the A3 template described here has a Creative Commons license; adapt and use as you see fit.

Featureban

My Featureban simulation game (Creative Commons again) is still going strong! One major revision this year (2.0) and a few minor tweaks along the way.

Clean Language and Cynefin

Perhaps (or perhaps not?) the surprise of the year: our most popular post is one in which I quite cautiously announce our integration of Clean Language and the Cynefin four points exercise into our workshops. Their integration is now well tested and we love them both separately and together! January will kick off with a short series of posts digging into this in a bit more detail.

Here’s to a similarly exciting and productive 2017! Will you join us?

Mike Burrows
Chesterfield, Derbyshire, England, December 2016


Agendashift-cover-thumb
Blog: Monthly roundups | Classic posts

Links: 
Home | Partner programme | Resources | ContactMike
Community: Slack | LinkedIn group | Twitter

The “obvious” question

First things first: the rename mooted in last week’s post has already been implemented. What was the “Agendashift debrief/action workshop” is now the Agendashift transformation mapping workshop. The same content in a more digestible order, with some additional and already-implemented improvements to be announced in the new year.

Anyway…

Remember this picture? It’s an example of the output from a Cynefin four points contextualisation exercise, taken from a training day earlier this year:

IMG_1523

There’s a slightly tongue-in-cheek question I like to ask when debriefing this exercise:

What’s the obvious question to ask about the items in the the Obvious corner?

The answer I’m looking for:

Why haven’t they been done already?

After the teasing comes a serious point that has become a recurring theme for my workshops: Too many organisations are full of smart people who can tell you what’s wrong and can give you a long list of sure-fire fixes, but nothing changes.

You might say that these organisations are uninterested in improvement, but I believe that in many cases it would be more constructive to say that they are incapable of following through. There is little to no visibility or accountability around anything change-related; the feedback loops (whether formal or informal) that do exist are likely to be overwhelmed with urgent delivery-related issues, with no provision for understanding and tracking improvements the systems that allow those issues to arise in the first place.

If that’s true for the Obvious corner, how will they fare in the Complex corner? If they can’t track obvious changes, how will they manage the kind of change that involves experiments – even experiments-within-experiments (pilot experiments) – and all the uncertainty that goes with that? Not well.

Conclusion? If change isn’t happening, don’t blame your staff. Instead:

  • Make sure that improvement work is treated as ‘real work’, prioritised, tracked, and rewarded as such
  • Keep it visible to any managers and other stakeholders whose commitment will be required in order for the more difficult changes to be realised
  • Provide safety, treating success and failure as near equals. Better to keep learning than never to dare anything difficult

Let me leave you with the relevant prompt from the Agendashift values-based delivery assessment:

We ensure that opportunities for improvement are recognised and systematically followed through

How well does that describe your organisation?


Agendashift-cover-thumb
Blog: Monthly roundups | Classic posts

Links: 
Home | Partner programme | Resources | ContactMike
Community: Slack | LinkedIn group | Twitter

The transformation map

Big day yesterday – it was the occasion of the very first Agendashift facilitator day, the first of many I hope! Here, in all its glory is the transformation map we produced:

transformation_map_leeds_2016_12_05

For the name transformation map we have workshop participant Tony Richards to thank. One of those things that seems obvious in retrospect (but still all credit to Tony), it’s a particular kind of story map (I described it as such), one whose ‘spine’ is a transformation journey.

The detail is driven from the 40+ prompts of the Agendashift values-based delivery assessment. Category by category (value by value or journey step by journey step) we:

  1. Prioritise prompts that represent areas of opportunity
  2. Identify obstacles that prevent the full realisation of the future reality described by the prompt
  3. “Flip” those obstacles into objectives (Clean Language provides some fun ways to do this)
  4. (Optional) Generate actions for those objectives

To set the right context for the transformation mapping process we explore existing strategic objectives and assess the current situation. This process builds agreement, creates opportunities for alignment, and ensures that the resulting transformation strategy is coherent not just by construction, but in context also.

Other learnings

Learnings for me, that is!

Between the outer wrapping of that strategic exploration and the meat of the transformation mapping exercise, most of my workshops have up until now included a series of exercises around hypothesis-driven change (HDC). Here, we take a small number of high priority outcomes, generate actions for them, and then choose just one action to reframe (Lean Startup-style) and develop (A3 style). Yesterday, the transition from this deep dive to the breadth of the mapping exercise felt difficult for some participants.

I’ve not noticed this difficulty in client workshops, but it could be that the facilitator day’s lack of a shared organisational context amplifies a problem of which I was previously unaware. Anyway, I take it seriously.

Long story short, in the next iteration of this workshop, the HDC exercises will be postponed until after the transformation mapping activity. Transformation mapping is now very much the core part of the day, to the extent that I’m very much inclined to rename the workshop as a whole after it!

This change has further significance: deferring the generation of actions makes outcomes the main unit of currency for most the day. It is often natural to use outcomes and actions somewhat interchangeably, but nevertheless I’m sure that this development is healthy, perhaps bringing our consciously non-prescriptive approach into sharper focus. Remember: inclusive • contextual • fulfilling • open!

Keep an eye on our events calendar for more of these public workshops; feel free to ask that we hold one near you (perhaps you can help us make it happen). And if you’d like me or a friendly neighbourhood Agendashift partner to assist you in building your own organisation’s transformation map, don’t hesitate to get in touch.


Agendashift-cover-thumb
Blog: Monthly roundups | Classic posts

Links: 
Home | Partner programme | Resources | ContactMike
Community: Slack | LinkedIn group | Twitter

Agendashift roundup, November 2016

I’m in Paris next week, so a little earlier this month! In this edition: Agendashift facilitator days; The 2016 survey; Øredev conference talks; A PhD study on Agile retrospectives; Upcoming events; Top posts

Agendashift facilitator days

The Leeds workshop on December 5th is only a week and bit away! If you’re a current or potential Agendashift partner wanting to practice some new workshop facilitation skills or you’d like to see what Agendashift might mean for your company, this is an ideal opportunity. Book your place [eventbrite] for just £265 (plus VAT where applicable). Existing Agendashift partners get a £50 discount, and any attendees who subsequently join the partner programme will then receive the equivalent benefit.

If the Leeds workshop seems too soon or inaccessible, there’s another one in London on January 19th. Register here; same discounts apply.

Watch this space for news of workshops in other locations. Hamburg early next year seems likely, and perhaps one in Scandinavia not long after. Do you think we should run one elsewhere? Get in touch!

The 2016 survey

Just a quick mention of the 2016 Agendashift global survey. If you haven’t participated, please do! See also What we hope to learn from the 2016 Agendashift global survey.

Øredev conference talks

Again, just a quick mention of something you may have missed: the videos from both my talks at Øredev earlier this month. Watch them here: Scaling without cross-functional teams / Servant leadership un-neutered.

A PhD study on Agile retrospectives

This is on behalf the University of Central Lancashire, the people who run Agile North (a conference that has been very good to me over the years). One of their PhD students is conducting a research study on Agile retrospectives and is keen to make contact with Agile teams. If you think you might be able to help, please let me know and I will introduce you.

Upcoming events

See also our new online events calendar, where we also feature events supported our partners.

Top posts


Agendashift-cover-thumb
Blog: Monthly roundups | Classic posts

Links: 
Home | Partner programme | Resources | ContactMike
Community: Slack | LinkedIn group | Twitter

A blocker waiting to happen (and it works both ways)

Dependency
A blocker waiting to happen

That’s a rather informal definition and it’s not strictly accurate (some blockers are unrelated to dependencies), but it will do! Certainly it’s more helpful than Wikipedia’s:

[A] dependency is a link amongst a project’s terminal elements.[citation needed]

In our consciously inclusive and non-prescriptive way, the full version of the Agendashift values-based delivery assessment implies two kinds of dependencies:

1.5 We identify dependencies between work items in good time and sequence them accordingly
1.6 We identify and manage dependencies on external teams or services

The first of those is usually straightforward to deal with: we take care not to start a work item (some kind of deliverable – a feature, say) until we know that its dependent work items (other features or required infrastructure) will be in place. In the simplest case, we just sequence work items into some natural order and deliver them one by one. We must be a little more careful if we want to take advantage of our capacity to work on items in parallel, but still the advice mostly boils down to the mantra “Don’t start what you can’t finish”.

That mantra applies to the second kind of dependency also. Here, we know (or really should know) that we can’t finish a work item without some external contribution. Even the best cross-functional team will find itself dependent on others from time to time! Under these circumstances, if our work is to flow smoothly we must be take active steps to ensure that things will come together at the right time.

That in turn means being in the habit of identifying our dependencies in good time, keeping them visible so that no-one makes the mistake of starting work prematurely, and engaging appropriately with the people on whom our work’s completion depends.

2015-02-25-08-01-42
A Story Map with external dependencies:  note the red flags bottom right

Just-in-time: It works both ways

Most people will read “appropriately” as “early enough” – early enough to ensure that our work won’t be delayed. This is a slightly selfish view however, and it’s worth looking at this from the perspective of the team on who we depend. From their side, a piece of work that is started too early is a piece of work that can’t be integrated, tested, deployed, validated, and so on. Ugh! This is the kind of work-in-progress (or inventory) that the organisation as a whole really doesn’t want. If we’re really serious about flow in the presence of dependencies, the Lean idea of just-in-time (JIT) implies some two way commitment!

This is one reason why the concept of service is so helpful. Whether customer-facing or internal, an effective service combines two things:

  1. A strong sense of what we’re delivering, to whom, and why
  2. The ability to manage expectations around performance

service-oriented organisation has both of these firmly established on both sides of all its dependencies, achieved through mainly bilateral coordination, not overly reliant on organisation-wide synchronisation. A very good thing to strive towards.

Do you find yourself continually struggling with dependencies or (the flip side of the same coin) excess organisational inventory? It’s a solvable problem. Get help!


Agendashift-cover-thumb
Blog: Monthly roundups | Classic posts

Links: 
Home | Partner programme | Resources | ContactMike
Community: Slack | LinkedIn group | Twitter

Scaling without cross-functional teams / Servant leadership un-neutered

Hot off the press from the Øredev conference (great work guys – the conference isn’t even finished yet), videos of my two talks.

Wednesday: Scaling without cross-functional teams. I’m grateful to track chair Martin Rosén-Lidholm not just for inviting me, but for suggesting this provocative title! It’s a brand new talk and I really enjoyed both writing and delivering it.

Scaling without cross-functional teams from Øredev Conference on Vimeo.

Thursday: Servant leadership un-neutered. I’ve given this talk several times this year, and I have to admit that early versions suffered from me trying to pack in too much material. I keep on editing  (I removed a slide between Hamburg on Tuesday and Malmö on Thursday) and it flows much better now.

Servant Leadership un-neutered from Øredev Conference on Vimeo.

Would you like to have either of these talks at your event? Get in touch!


Agendashift-cover-thumb
Blog: Monthly roundups | Classic posts

Links: 
Home | Partner programme | Resources | ContactMike
Community: Slack | LinkedIn group | Twitter

Explaining Agendashift’s “sliders”

I often get asked how this visualisation works, and in particular what the blue and darker grey bars do. “They’re just a measure of spread” is the quick answer. A longer answer is that their calculations can be inferred from other clues in the UI – not 100% helpful!

screenshot-2016-11-09-10-31-28

Each of the scores – 2.7, 2.9, and 3.4 in this example – is an interquartile mean, sometimes IQM or midmean. To calculate one of these, we take all the relevant scores, sort them, discard the top and bottom quartiles (and along with them any outliers), and calculate the mean of the remaining data points. It is described as a robust statistic, one that is not easily influenced by errors.

Looking at prompt 4.1 in the picture, we can say informally that the “average of the middle half” of the scores given to this prompt is 2.7 (on a scale of 1 to 4). We might guess that the majority answers lie between 2 and 3, with more 3’s than 2’s. Not “nailing it” yet, but “getting there”.

The calculations for the bars are very similar, but here we do want to be influenced by the extremes. The left and right ends of the darker grey bars show the mean of the bottom and top quartiles respectively, the most extreme answers at the low and high ends of the scale. Notice that for prompts 4.2 and 4.3, these bars extend all the way to the right. At a glance, we know that at least a quarter of the scores here were 4’s (since their mean is 4, and there can be no scores higher than 4).

The blue bars are also influenced by extremes, but moderated by more typical scores. The left and right ends here show the mean of the bottom and top halves respectively. Looking at prompt 4.3, we can infer that nearly half the scores here were 4’s. Awesome!


Agendashift-cover-thumb
Blog: Monthly roundups | Classic posts

Links: 
Home | Partner programme | Resources | ContactMike
Community: Slack | LinkedIn group | Twitter