Symptom of Anti-Agility: CRM Groups

Collapsed_Bridge_Narrower

I haven’t written in a bit (well I have actually, but on Excella’s Insight blog), but I wanted to write about an anti-pattern I am seeing in one of our clients. Many have written that management seems to think of “Agile” as only within development teams, and forget that this Lean and Agile thinking needs to permeate everywhere.  It’s a dysfunction to continue working on…

So let me give you the example I am seeing so we can talk in more concrete terms.

The organization has had a rocky past between central IT and the business. Software development is distributed in various business units as well as a central IT shop (I’m staying away from actual terms the customer uses BTW). Central IT also does considerably more though, such as manage the network, run a server farm or three, manage cloud providers, email and content management services, etc.

The complaints from the business have been articulated as (in no particular order):

  • I have to know who to call in order to get good service; any official channel for requests is difficult to know.
  • Service is often slow and paper/form intensive.
  • When I use any official channel, it doesn’t necessarily get routed to the right location.
  • I’m not told everything I need to do to get my request fulfilled, resulting in delays.
  • I don’t know the status on requests that have a longer time to fulfill, nor have I been told or know where to go to find out my status.
  • I’m uncertain if any feedback I provide is acted upon.

I’m certain everyone has seen these before in some mix.  IT also has a set of complaints:

  • People go to whoever they happen to know that is related to the request they want to make to get service. This eats into people’s time without management having much knowledge of it (perhaps the immediate supervisor knows, but no one else).
  • IT needs to begin a charge-back model due to budget restructuring that is removing a great deal of central ITs funding, thus more knowledge of requests and services is needed to be known. The manner in which requests are coming does not provide a means to track it.
  • The business sides doesn’t see the great work we are doing.
  • The right people in IT don’t receive the needed feedback.
  • IT has a blemished image/brand and are thus not viewed as a valuable partner.
  • The CIO can’t keep up with the requests given to him by his peers; too many are bubbling up and being made directly to him.

If you work in an IT organization, particularly as a senior manager type, how many of these have you seen? Before I go into how to handle these with some Agility, let’s look at what this organization is doing that I consider an anti-pattern; literally anti-Agility thinking.

The senior manager tasked with solving this sees this primarily as a communications problem in 3 areas:

  • Routing to the right people to do the work
  • Taking in feedback on ITs performance
  • Improving the communications on good performance (improving the “brand”)

To solve this, they are standing up a Customer Relations Group that will take in initial requests/requirements, receive feedback about performance during and at the end of the work and provide it to the group(s) that performed it, and get the word out on the good stuff IT does.

They are starting by creating a master catalog of services IT provides (which on the back-end will have costs associated with them). It’s unclear whether these costs and/or the parts of the IT organization that will perform them will be a part of this catalog.  So far not bad… They also will stand up a single intake service (along with an online form) to process these needs, then ‘interview’ the customer to get any additional information, and route this request to the proper parts of IT.  It seems at this point there will be a hand-off; what is unclear is how this hand-off will work if multiple parts of the organization are involved simultaneously. If software development is the primary concern, it will be handed off to a development team (or a new team will be stood up).

This new Customer Relations Group will also query the customers periodically to find out how well the various parts are doing and give this to the right part of the organization. It will also give any responses back to the customer. And finally it will create some marketing material and positive ‘press’ to help sell IT services.

To keep this from being a burden on the current IT organization, the bulk of this work will be contracted out to a big name firm that everyone respects. Sounds great doesn’t it!? Every organization needs this, right?

As well as intentioned at this group (and its contractors) may be, this creates several dysfunctions.

  1. This is actually adding an additional step that will actually slow requests getting to the right people. This will increase the time to service, probably decreasing happiness, perhaps not initially, but certainly in the long run.
  2. It adds a hand-off of information so that the people needing it are getting it second-hand. This will lead to greater misunderstandings between the groups that need to work together.
  3. Feedback and working communications are at least partly being removed from the group that needs them directly.
  4. There is an assumption that a one-size-fits-all intake process can accommodate getting all of the unique needs a customer needs to portray to a unique supplier. Requests for an email distribution list would be vastly different than one for a software development project, or just even business analysis services for a development project.
  5. Messaging (branding) will be coming from a third party not responsible for any of the results.

Even worse though, there are fundamental root-cause problems being masked over.  For example, why does the business feel feedback they give is not listened to and acted upon? This solution isn’t going to address this root-cause concern. What is causing the long lead-time for IT to respond to business needs? Why are we trying to create a standard process for intake and routing as opposed to simply better connecting people to those that would supply the services and give proper visibility into the incoming work, but allow a self-routing approach? Why do we need to do a charge-back for the services internally as opposed to getting the budget reallocated properly to pay for them?

So how would I approach these items? I’d start with challenging the fundamental way things are done. I would learn where are the bottlenecks causing the unacceptable lead-time. I’d investigate the root-causes to the image/branding and see how to solve those. I’d see how I could make a catalog of services attached to the people that provide the services and work them to create mechanisms that give me an understanding of the allocation of requests. And I would at least talk with the budget personnel to find out how I could simply get the budget allocated properly; if that couldn’t be done, I’d make my service costs transparent to those when they look up my services. If I wanted something Customer Relationship-like, I’d perhaps think about deploying customer relationship software to all the groups directly, if evidence showed it would help.

Bottomline: I’d reduce hand-offs and keep with the spirit of individuals and interactions over processes and tools. I’d do the simplest thing I think is in the right direction and then retrospect on how that is working for me.

 

TWEET Your Feedback

pixar-birds-wallpapers-movies-widescreen-images-157470

This post was prompted by Jurgen Appelo’s excellent post on giving a Feedback Wrap on Forbes.

I really like this post as it gives you an extremely useful way to express feedback in a manner that will help the receiver actually take action.  It also helps them become aware of future behaviors they may need to change.

Giving good feedback is important, whether it is to superiors, subordinates, or peers. Like Jurgen, I won’t claim to be perfect at doing this and more than once, I know I have provided useless and sometimes hurtful feedback. So to provide a bit of additonal advice as a wrapper around what Jurgen is recommending, I wanted to share an acronym I learned at Culture Camp DC 2012 from Chad Wolfsheimer of the Motley Fool.  The acronym is TWEET; here’s how it breaks down:

Take note of impact

This part is recognizing a meaning to the behavior you want to give feedback on; what is this behavior doing to you, others, a team, and/or the organization. If there isn’t any impact (or perhaps if it truly is trivial), then ask yourself is this feedback going to be useful?

Write down (organize thoughts)

Chad recommends writing down your thoughts, but he did offer up that due to the necessary timing you may not have this opportunity. None-the-less, take a mental step back and organize how you plan to present it; non-organized feedback will come across as a rambling complaint and not achieve what you want.  Using Jurgen’s Feedback Wrap technique is an excellent way to do this.

Empathize

Before jumping and giving feedback, try to understand the context the other person may have. Empathy in this case is not only what they may be feeling emotionally, but also what their mental model may be on why they are exhibiting the behaviors they are. Trying to understand this may help give you insight into how to deliver it so that it is received well.

design it be Effective

Using the Feedback wrap as guidance to organizing it and any insights you may have gained through empathizing, think through how the delivery can be made effective.  After all, if the feedback is ignored or it spawns a defensive mechanism, it probably won’t likely alter the behavior you want changed.

Time it appropriately

We’ve heard how feedback should be timely; Chad recommends and I agree to think about timing. Often just after the behavior is exhibited is the right time, but at other times it may be worth making a determination as to the most appropriate time to deliver the feedback to maximize its reception.

On top of the two great ways to look at feedback that Jurgen and Chad have presented, I also recommend including inquiry.  Asking a few key questions can help you both empathize AND open up the recipient’s mind about the behavior you want to change. Be careful what questions you ask though; for example ‘Why’ questions may put the recipient on the defensive. Try and use open-ended questions as well as this prompts some thinking.  Here’s an example of a question that may work –

After you presented your critique of John’s database design, what did you notice about people’s reactions, and in particular John’s, to your statements?

If the person you are providing feedback hadn’t noticed anything, this question may prompt them to think through what may have been happening and help the recipient self-realize the impact. This makes your job much easier.

I’d avoid the following –

Did you notice how people felt dejected, and in particular John, after you critiqued his database design?

While that may be indeed what you noticed, it is your own mental model that produced that. Even if your recipient might come to the same conclusion, this closed question places her or him on the defensive and not in a place for self-reflection of their behaviors.

I hope you found this post useful, if you have any tips or tricks you use in giving feedback, feel free to leave a comment or tweet at me!

 

Agile Coach Camp US – Neat Learnings

I attended several sessions at Agile Coach Camp; I was really impressed by the topics proposed this year. I went to some on Business/Organizational Agility, improving feedback/listening skills, one on creating Joy at work, and several related to using games to teach various Agile concepts. I’ll have to admit, I got lighter on the subject matter as the Camp wore on… Anyone that knows me usually knows I have no fear in proposing 2-3 topics.  This year I proposed none.  I was a bit too dain bread to host one given all the distractions and effort that went into running the Camp itself.

Before I jump into my key learnings/highlights, I was very glad to see one of the emerging themes be one of invitation over imposition. So many organizations are now jumping onto the Agile bandwagon and imposing Agile from above as opposed to helping it emerge; and then we wonder why there is resistance! I also really liked that there was good discussion on various technical topics as well; I often feel these get forgotten.  It’s important for us as a coaching community to understood how we can help organizations adopt things that matter and for software development they ummm… seem… to be technical in nature.

So my highlights; I would be remiss if I did not say one highlight was our extremely energetic facilitator Trica Chirumbole.  I think she brought a great energy to the Camp form opening to closing circles.

I was glad that my first session was one that Ryan Ripley ran to clear up some of the misperceptions people have about why an organization should adopt Agile. We seemed to come up with some great clarifying points to help our organizations or clients understand what to expect as an end result as well as various interim improvements to expect along their journey. Here were some of the key take aways:

  • a focus on improving organizational adaptability/responsiveness
  • use of data to make decisions, but not without regard of what the organization’s people will be undertaking
  • more transparency into organizational performance; risks more visible so better decisions can be made
  • better trust within the organization
  • containing failure and learning from it
  • improved employee engagement and retention

The title of the session was it’s NOT about being Better, Faster, Cheaper; though we rearranged it to mean this by stating: Better = more predictability and customer-focus, Faster = is time to market, not just meeting a schedule, and Cheaper = a focus on producing more value, but not reducing costs.  The hard part we found for measuring organizational performance on these is few organizations have a baseline measurement for any of them; in fact we came up with the hashtag #nobaseline to tweet about these instances. Reminding me I could use that with my current client 🙂

Ryan later ran a follow-in discussion from a session we had in the Open Jam session of Path to Agility in Columbus on creating Joy at work.  It was a complementary session to the earlier session as it focused on the human aspects of making those aspects happen. Since we had a new crowd, we really spent a third of the session kind of bringing them up to speed on our thoughts (at least it felt that way). I have an earlier post to help you. Once there though, we explored why Joy was more important than happiness though several people still thought they were synynomous.  Quite a bit of the conversation focused on how NOT imposing choices on people (what Daniel Pink would refer to as Autonomy) is key to this.  Some other also had it relating towards accomplishment (there’s Mastery) towards a purpose. I mentioned that I like Jurgen Appelo’s CHAMPFROGS; it feels more complete.  Since then, after reading Frédéric Laloux’s book, Reinventing Organizations, I might also say Joy is the integral of Wholeness from time = 0 to the present.  I still also stand by our earlier equation as well from Path to Agility.

I’m going to go quick over some of the rest as I feel I have been rambling a bit; I went to a games session hosted by Declan Whelan and George Dinwiddie on games they had come across or developed.  Declan presented Tom Grant’s tech debt game; everyone played it different and got results that demonstrated WHY we should make investments into things like automated testing and continuous integration. George showcased a game that he has been slowly evolving to show how refactoring works – it more demonstrated how software is malleable and we should treat it as such.  This is of course on its own very valuable.

I attended two other sessions I want to highlight, also both ‘games’-oriented: Mark Sheffield held sort of a games round-up.  I learned several new games to research and variants of games that would prove useful for helping teams and managers understand things better.  Andrew Annett ran a session on the Empathy Toy, which is all about common cognitive empathy (aka developing shared mental models).  This toy is fantastic, every coach should have to play this – you are always trying to find ways to bridge the gap in understanding.  My cohort Ken Furlong and i are already developing new ways to use it.

We had 2 happy hours before and during Camp as well as some food shared in various locations – it was awesome catching up with Diana Larsen, Daniel Mezick, Aaron and Brian Kopel, Jeremy Willets, Kevin Goff, faye Thompson, Declan Whelan, Tim Ottinger, and Ellen Grove at length (during Agile2015, I also had the chance to spend some time with my friends Woody Zuill, Pawel Brodzinski, and Chuck Suscheck at length too).

T-Shaped/H-Shaped Contracting Officers

Recently the US Digital Services and Office of Federal Procurement Policy issued an OMB Challenge; in it they discuss how contracting officers need to be more knowledgeable in digital services procurements. (Digital Services seems to be the new 18F-ish buzzword for user-centric software development, though they also reference cloud-based services…)

In this challenge, they mention creating depth of knowledge in digital services procurement, however they also suggest a desire to increase their business savviness, though they don’t express exactly what is meant.

T-shaped people have both depth and breadth of expertiseThis prompts me to simply point out that contracting officers and specialists (as well as any acquisition-related professional) are needed to aspire to become generalizing specialists or T-shaped people.  What do I mean by this?  For a contracting officer, this means becoming not only steeped in contracting services, but knowing enough about information technology to understand what may or may not apply to procurements. I’d also suggest getting more knowledgeable in their department’s or agency’s mission and understanding their needs earlier on is what will also aid them in becoming better at digital services procurements.

The challenge wants a CORE-Plus curriculum; IMHO this indicates that the government is interested in beginning to create contracting officers that have more breadth.  This helps attune their contributions to become more valuable as their knowledge increases to better align with the services being procured.  In some ways the desire to have contracting officers undergo a CORE-Plus certification, means they will be more like H-shaped people with some deper knowledge of digital services technologies as well.

Contracting, particularly in the government, is a complex undertaking.  As someone who maintained several DAWIA (Defense Acquisition Workforce Improvement Act) certifications myself, I can attest to how valuable it is for personnel to have a broader understanding for what they are acquiring and how it fits into the needs of the organization that will utilize it.

For an excellent general write-up on what T-shaped people are, drop by Darren Negraeff’s post The Importance of T-Shaped Individuals.  It contains links to further reading and is also where the T-shaped image above comes from…

A Short Essay on Using Models – Why Should You Use Them & Why You Should Create Some

EA-7L_Corsair_Line_Drawing I use many models in my thinking, whether they are mine or someone else’s, yet I don’t think of myself as a theorist. I thought it may be helpful to some on why models are so valuable to a pragmatist. Another word for model is framework…

“essentially, all models are wrong, but some are useful”

George E.P. Box

This quote is the first thing to remember when you begin using any model; you need to remember that at some point a model will break down and no longer support what you were using it for…  Like a lean start-up idea, create and use models passionately, but stop using them the moment evidence points that they are no longer helpful.  (he nice thing about a model though is that generally this means you have crossed an edge-case where the model doesn’t work any longer, but may still be useful in the long run.  If the model consistently doesn’t work, then perhaps the model has some invalid assumptions.  Exploring these assumptions then may help you refine the model into something that once again works or to find or develop a model that does work under the broader circumstances.

This brings me to the next point – ALWAYS realize models have a set of assumptions.  Explore how the model works under these assumptions.  This helps you understand when the model may be useful and when it may not. With that, why do you need them if you are simply someone (particularly a coach or manager) who needs to help people get things done?

Models help you understand systems; they may not provide a means to achieve an answer, but may simply may provide a means for organizing your thoughts.  The Cynefin model by David Snowden is one of these latter ones – it can help you understand the problem space you are exploring for decision-making. Finding models that can represent systems or at least significant and important portions of a system is mostly useful for helping you organize your thoughts.  The act of thinking through when and how these apply including valid and invalid assumptions about variables, algorithms, or organization (for more pictorial models) really helps you determine on which things to pay attention.  Even if you find the model doesn’t work, the amount of thinking you went through will serve you well.

And I invite you, particularly when you don’t find a model that seems to represent what you need, to try and think through creating one.  Don’t worry about it being perfect, you can always adapt the model after inspecting how it works.  Again, you are using this to organize your thoughts.  Creating a model could be as simple as combining models; Jurgen Appelo’s CHAMPFROGS model about motivation does this.  It appears Jurgen saw gaps, overlaps, and some inconsistencies in representation and blended a new model to make it more clear to him.

It’s also extremely useful to find where different models connect in explaining the same observations (data) differently.  This helps you understand where options may be found and where the thinking on these has many dimensions, which again exposes assumptions about the models.

Going back to the usefulness, one huge benefit for applying or creating a model is stepping back from tactical thinking to a more strategic layer.  This helps in prioritizing based on importance over simple urgency.

People serving as coaches and managers are there to help the people improve the system, you can do this best when you have your own thoughts organized. Models can be an essential tool in selecting and organizing the particular tools and techniques needed to apply.

Locking Cadences to Optimize the Whole Scaled System – Not Really…

I had a reminder through some recent comments that people view locking cadences in step as a means for optimizing the whole of the system and not for individual teams (by allowing them to choose the cadences at which they wish to deliver).  this is used to justified in the case of when you have a need for a program.  I think this is missing the point, so I am going to go through some explanations.  I really like how Jurgen Appelo has applied David Snowden’s Cynefin framework to work systems so I am going to illustrate my rationale using some of his work.

So let us start with a team:

Programs_Explained_in_Mgmt3.0_speak-1Teams are simple to understand, predominantly because of their simple structure with few people; however they are  complex in nature because we are dealing with humans.  Sometimes we can’t even predict our own behavior, much less a whole team’s.  Next, let’s think of where most policies and processes wind up…Programs_Explained_in_Mgmt3.0_speak-2Good processes (and their accompanying policies), try to add order into systems; this is particularly true of many of the scaling systems out there (SAFe, DAD, to some degree LeSS) where structure and process is imposed on the ‘program’ system in order to achieve more predictability.  Unfortunately most of these are quite complicated in nature; some have helped by providing well diagrammed (some even animated) pictures, but there is still no denying the complicated nature of their arrangements to attempt to get predictability.

This is very well intentioned, yet what happens in reality is the following:

Programs_Explained_in_Mgmt3.0_speak-3The complicated-ordered process thrown on a simple-complex team yields a complicated-complex result.  This isn’t achieving what we wanted… and we’re just talking about a single team! And if we expand this to many teams such as we would have in a program, this is the best case we can hope to achieve.  It may become complicated and chaotic as the additive results yield less predictable results. Programs_Explained_in_Mgmt3.0_speak-4So why is this happening?

It’s because we humans create complex social systems.  There’s a reason why we value individuals and interactions over processes and tools; the latter can be complicated in nature perhaps and yet they are ordered in nature, while people systems can be either simple or complicated, yet are always at best complex.  People aren’t robots, so our behavior is never entirely predictable.

And yet… we try and put systems in place that have unintended consequences, such as imposing cadences on teams to get more order (predictability) out of them.  Think about the last time you had something forced on you that you disdained; it probably had you at best working at less than motivated – it sucked the motivation out of you, so you didn’t perform as predictably as desired. And at worst case, you went and found a new job and now the team was thrown into reforming and restorming to get back to renorming and performing.

Each team and its individuals will be different, perhaps some won’t care that much about the ‘normalization’ of cadence.  But some will have deep negative impacts that will occur.

So I ask you what ‘system’ are we trying to optimize? The process or the people?  Imposing a process to de-optimize how humans perform seems to me have many potential negative longterm effects; besides losing good people or demotivating people, even if this happens to only one team out of ten, it sends a signal that people don’t control their work system at all, that any element can be changed on a whim. Basically apply the pants principle and let teams adopt as simple a process as possible, including the orchestration.  As Saint-Exupery said, simplicity is not achieved by deciding on not when there is more to add, but deciding on when there is not more to take away.

Programs_Explained_in_Mgmt3.0_speak-6 Does this mean that locking cadences can’t ever be adopted? Not at all… Facilitate teams to select a good cadence within themselves firstand then collaborate with other teams to find how to best orchestrate delivery.  This may result in lockstep cadences or perhaps a creative branching and merging strategy. This could be done during team chartering by holding a futurespective. Regular intra-team retrospectives could help teams identify when changes need to occur. Simply installing a locked cadence at the beginning may result in a sub-optimal approach as it overlooks the people part of the equation.

Calculating Joy and Fulfillment

At the Path to Agility, several of us got together and had an open discussion about what possible relationships Happiness, Joy, Purpose, and Passion had.  In attendance was Ryan Ripley, Faye Thompson, Joe Astolfi, Jeremy Willets, and Kevin Goff.  Others dropped in from time to time as well and provided some input.  Ryan kickstarted it with a premise that focusing on pursing solely creating a happy team(s) destroy longterm joy and fulfillment.  The discussions were contained in the photo of all the stickies (semi-organized into various areas):

image1

We discussed many different things, and I’ll mostly focus on my take aways and contributions.  We’re still discussing this (primarily via twitter currently), so it’s an ever evolving concept and I am not sure we’re all in agreement yet.

Happiness was felt to be a short term thing, while Joy yielded a long term gratification. I started my (useful) input showing how happiness of a team over time can be captured via a Niko-Niko calendar and that this is useful in understanding whether a team is working well together.  Ryan still said that a happy team may not be joyous, but we did at one point all seem to agree that at some point if a team had little to no happiness occurring, then it was unlikely they would feel joy.  This got me to drawing a stacked area chart; the x-axis is time and the y-axis is the amount of joy felt by the team.  The areas that add up to this happiness (which is more volatile), passion (mildly volatile), and purpose (little volatility).

I wish we had spent more time coming to some form of agreement on Passion and what it means; I defined Passion as the collective sum of the motivations I have.  I really like the CHAMPFROGS set that Jurgen Appelo has created.  I think some of the inconsistencies showing up in our Twitter convos deals with each of us having a different mental model around passion.  These passions can change some over time.

Alignment on a purpose is also very important and alignment of this purpose with my longterm passion is also very important. It’s this latter part that gives me motivation to pursue it, yet if it is a continuous unhappy environment then I will also find it difficult to stay focused. We ultimately settled into this equation, which I wrote onto the whiteboard under the advertisement for our session:

Joy_equation

This equation states that Joy is a function of the Length of Happiness I feel multiplied in the pursuit of Purpose in addition to the Passion I bring to it.  Thus if I have little time I spend feeling happy as I pursue a purpose, then I will not feel longterm Joy.  Likewise, if I have no purpose, I also get no Joy either; this because Joy is the feeling of Fulfillment we get (Joy = Fulfillment).  Lastly, it needs to be aligned with passion as if my passion would rather pursue something else, then I likewise will have little Joy.  If we bump this from an I to a We for a team or organization, it means getting alignment on purpose and passion while having a supportive environment which increases happiness.

The important aspect to me though is the role of leadership in this; when exercising leadership, our job is to discover people’s passions, help them see how they align with a collective purpose.  It also means that I want to create this supportive environment, but not pursue short term hygenic treatments to make people happy, they need to be factors that create longterm possibilities for team members to be happy.  An example of a longer term factor would be one of safety as one would find in Anzeneering. To create Joy, leaders (which in a self-organizing team can actually be any team member)  is the application of the Antimatter Principle to attend to people’s needs.

Addition (that I forgot to mention, but it was discussed and is very relevant), Tobias Mayer has an excellent post that if you attempt to encode someone’s values, you kill that person’s spirit.  This can be true even what is being imposed is happiness; this will not create longterm Joy.