Views of Estimating and Not Estimating for an Executive

This post was developed in order to give a longer response to Henrik Ebbeskog’s.

My personal response to this tweet is that it represents a one-sided static and unsophisticated view of what a CEO may want. I am going to use this question as launch point to show that a range is possible. Which one may be ‘correct’ is highly dependent on the CEO’s mental models (and motivations), the organization, and the environment in which the organization finds itself. In this post, I am only trying to disprove the hypothesis that the CEO must understand some estimate from a traditional point of view at the beginning of an initiative. I’m also going to explore this from a financial sense, not so much from what a team may do around story points, et cetera, though I will make a short mention of it at the end.

For context that we can work within, the scenario is a SaaS company that provides financial compliance services. The company already has revenues in the high tens of millions of dollars and thus is not a start-up. The CEO is interested potentially expanding into a new market by launching new product services in helping clients monitor environmental compliance.

A Traditional Estimation Mindset

If the CEO is in a traditional estimation mindset, she or he will be interested in knowing as much about the iron triangle’s values of cost, time, and scope as possible. The CEO will turn to marketing (the Chief Marketing Officer if they have one) and ask of them “what are all the environmental compliance monitoring needs, who are our potential customers, and what is the potential revenue for these services?” Before marketing runs off and does this research, the CEO also asks, “how long will it take you to research these, and how much will this research will cost?” These are of course fair enough questions; the CEO wants to know the potential cost of the information before giving a go-ahead and whether it can be done in a reasonable timeframe.

OK, an estimate is made on cost and time (hopefully using historic data if they have it) the answer sounds reasonable to the CEO, so the green light to proceed is given. So marketing proceeds with the work they do in order to understand the market space taking about one quarter to do so at roughly $150K; this is on schedule and on budget from the estimate they gave the CEO (1 quarter and $150K+/-$10K; woot! win!). They may research the web on compliance needs, survey companies, see if competitors exist, et cetera. It looks promising; the revenue looks like it will be $10M for the first year, $20M the second year, and an estimated $30M the third year.

Now the CEO turns to the Chief Technical Officer asking, “how long will it take you to build this and when will it be done?” as he hands marketing’s finding on scope to him. Of course the CTO doesn’t give her or him a flippant answer, so the CTO goes back and pulls together a cross-functional team, including an experienced product manager, (let’s assume they have been using Scrum/XP practices for years) and this team defines an MVP with a rough price tag of $225K+/-$50K to get there. They also come up with an estimate of a first marketable release a quarter after that, and (in talking with marketing) another 2 subsequent improvement releases based on prioritized environmental monitoring needs the next two quarters after that for a total cost of $900K+/-$200K. Cool beans! Let’s go!

They execute and for simplicities sake they stay true to their estimate of $900 and $225K per quarter. I want to state that once the team was pulled together, the cost over a time interval is known if it is a stable cross-functional team.

The mindset here is understanding risk before executing (and of course managing it during execution).

A Lean Start-up Mindset

The CEO is interested in exploring the same environmental compliance space. He talks with his other executives and they decide to form a cross-functional team of marketing, which includes an experienced product manager, and IT personnel. They pull together a hypothesis of customer, problem, and solution and identify a set of assumptions about this. The team and executives set a vision for the need and boundary constraints that ensure it stays aligned with the company’s core vision and mission. Within these constraints is a set of questions that if understood state criteria for a transition state to a development effort as it provides enough detail to define an MVP and MMP as well as what the revenue stream for the MMP and other potential known releases of the SaaS product will be. The CMO is appointed as the oversight on this effort and agree that after each assumption is tested he will review whether to proceed, pivot, or kill. It’s worth noting at this point, none of the iron triangle is known. Costs per week of this assigned team are known (just like AFTER marketing provided the estimate above and were told to execute their research).

The first assumption is that monitoring a particular environmental compliance aspect is unserved in the marketplace. The team tries to find evidence of this through market research and a survey to their financial service customers in the same space. It is not disproved, so the CMO gives a proceed (or in start-up terms persevere) signal. They test the next assumption, and then the next. Sometimes, they build a quick prototype to see if a particular compliance rule can be enabled (it was the riskiest assumption). At the end of a quarter and $150K they know what the MVP and MMP look like and what the next 2 releases look like. They have the same revenue stream predicted as the traditional team.

At this point the team is reconfigured to look like the Scrum/XP team above and proceed (however, no estimate is asked for) and we’ll say that they deliver just as the team above costing $900K. The important point is that the same stable cost over the time intervals operates as above. At each quarter a proceed or kill decision is made based on the throughput of work was completed to what remains. This is a form of estimation – yes I realize it. What is different in this case is when the estimate is made; I didn’t start with an estimate. A rougher approach is simply looking at the remaining backlog compared to what’s left. I could also evaluate the marketplace at this point using the competitive analysis approach I had done and see if I want to continue (basing a decision on expected value in terms of a change in potential revenue – another form of estimate).

Other Alternatives

I could choose to do a traditional approach to marketing and then build without the estimate on how much it will cost. I could reverse this and do a lean start-up approach to understanding the market demand and transition to an estimated approach as well.

One thing to note: the lean start-up approach could be modified so that once the MVP (or MMP) was defined, the company could actually start building knowing they have some revenue stream that will come in; they may not know whether the company will get to the revenue stream as predicted though. This would decrease time to market for the MMP and may allow it to even expand into the other markets or it could decide to not and become a complementary service companies purchase.

Take-Aways for the Reader

First, I painted a rosy picture of delivery. It is very likely delivery will not go as smoothly as this. Thus when I reach the end of a quarter where a release is defined, I need to decide whether to continue or not or release with what I have. In a traditional, estimated viewpoint, I am deciding whether to add more time to the schedule (and potentially run over budget as a result) to release with the fully expected scope or release with less scope on time and at budget. Regardless of whether I estimated the length of time it took me or not, I can use my actual throughput of work as the predictor or not on whether to continue. Again, as I mentioned before this is a form of estimation; I am just choosing to do it later.

Second, I didn’t get into estimation that may occur (or not) by the team.

The primary use of story points (or another team estimation method on stories) is to know whether a story is small enough to be completed easily within an iteration. Some teams get really good at understanding their sizing and can stop using story points. (Lunar Logic’s estimation cards are a good insight into this, every story is either a 1 – we can take it on, TFB – too f-ing big, or NFC – no f-ing clue.) I encourage teams to examine the story’s independence and testability to gain this understanding as these two parts of the INVEST criteria are what feed the complexity thinking one needs to understand in applying story points. Teams can still measure throughput and lead time as these can be useful for later questions when an estimate may be needed about ‘how much’ or ‘how long’.

Third, I’d like to change the convo a little a bit. I personally think value and cost are decoupled. Net value (value minus cost aka ROI) are coupled. A great place to get a sense of this is Reinventing Project Management by Shenhar and Dvir. In this book, the authors describe two scenarios where the cost of the project had nothing to do with the end value of what was produced. Another change is ridding ourselves of the use of project thinking when we are doing product efforts. Product life-cycles extend beyond initial delivery and when use project thinking we often short change understanding of both costs and value in the long-term, whether we estimate or not.

Fourth, I hope this gives some insight into when choices can be made about estimation; it is not a simple binary answer, but one of fidelity. In some cases, one will want to run several detailed simulations in order to understand whether an undertaking should be done. In other cases, maybe we can just get started with none what-so-ever. Humans actually never escape mental models of estimation however, even a zero on this range assumes we will get some learning insight that has value and that in itself is an intuitive estimate. We certainly discovered this at the first Agile Dialogues unconference. (Biggest personal disappointment at this unconference is that the person that helped shape the theme then chose not to come after indicating they would.) What the thinking in the #noestimates ‘movement’ is trying to do is change the nature of this and question what our assumptions and beliefs are about what and when to estimate.

I’ll close with saying that there are people that add well to this conversation – they bring in well-formulated opinions. There are others that prefer to provoke – this occurs on both sides unfortunately. I personally seek actual dialogue so we can get out of binary thinking on this (see the Agile Bramble). I point out circumstances where not estimating work not to debate that not estimating is the path to follow, I’ve never said ‘never estimate’, but to have more dialogue of when we should undertake it or not and what we should estimate. Notice I didn’t say ‘if’. I’ve had someone state I evidently had no evidence when I have given some. I’m also not interested in endless debate – ask yourself do you feel you need to ‘win’ an argument. If so, you are not in a mindset for dialogue or learning, but to prove a point.

With this, I hope I have shown that the Rule of 3 applies 🙂

 

How do you measure sustainable pace?

This was a question posed by my esteemed colleague Bernd Schiffer (@berndschiffer) on Twitter. This is a complicated thing to measure. We all know what effects unsustainable pace has, AND often when they show up, it’s too late. I’m going to divide this post into two segments; first will be early warning signs that a pace may be becoming unsustainable, so you can try and nip it in the bud early. Second will be how to determine that your pace is likely sustainable. (I say likely as it’s always possible these possible metrics may not catch everything.)

Early Warning Signs060417-N-9079D-108

So let’s start with signs that one (most likely a coach or Scrum Master or other suitable servant leader/team facilitator) may use to find out if a team may start to hit an unsustainable pace. None of these on their own may be enough to indicate encroachment of an unsustainable pace, so ensure you get a balanced view.

If you have access to time card data, and if people are honestly reporting their hours, you can look at how the hours they record are trending. This can help you spot both individuals that are undertaking an unsustainable pace as well as the team. This really needs to be complemented with a gemba walk so you know what are normal hours for people and when people may be burning the midnight oil. The occasional late night may be ok; perhaps the individual or team has an interesting problem they want to solve before going home. If this is a regular occurrence, then you most likely have an indicator that an unsustainable pace is starting to happen.

Look at check-in trends. Do they become more rapid in pace at the end of an iteration or before some significant milestone? Do these correlate to an increase in broken builds or failed tests? Does test coverage slip around these? These may be indicators that people are getting rushed in their work. Along with these, trends in escaped defects may also indicate whether a team is receiving pressure to deliver.

If you are running a Niko-Niko or otherwise taking a pulse of the team, then downward dips or loss of stability in happiness may likewise be an indicator that the pace may be becoming unsustainable.

Lastly, consistent carry over of uncompleted work between iterations, measured in story points if you are using them or just in the number of stories, tasks, et cetera, can be an indicator of possibly approaching an unsustainable pace.

None of these on their own though make for a good set of measures, only by cross-correlating them can you possible get a sense of a team’s pace getting to where it may begin to collapse under pressure.

So what should you do? Well if you are seeing these metrics, you will need to 1) confirm that the pace is truly becoming unsustainable and 2) remove the pressure in a manner suitable to getting the desired results. For both of these, sitting down one-on-one and having some conversations as well as conducting some retrospection as a team on what is happening may give more insight than any metrics could. This will also uncover the pressure that is causing it in the first place. The pressure may be appropriate; what may not be appropriate is the reaction. For example, suppose the product owner is not accepting many stories because of a team not meeting all their acceptance criteria. The team decides to begin working late rather than reduce the number of stories they take in as a means for ensuring they get all the acceptance criteria completed. The response is the issue, not the pressure.

Measuring Sustainable PacePressure-Gauge-Pressure-Detection-System-Heat-Meter-161160

With the above, you’d think it perhaps good enough to just look for the absence of those negative signs. Presuming people are truly being open and honest AND also aware of the pace becoming unsustainable then yes, the absence may work. But what if workdays have been regular, but then every so often a few extra hours go in, then suddenly there is a sharp uptick in the number of hours? That may take what was tolerable to intolerable, particularly if it causes stresses between workers where some have family commitments and others don’t and thus get ‘stuck’.

A better measure for maintaining sustainability on a team may be noting how often the team can push back on requests that regularly cause these extra hours. This means the team can choose when they want to do them or not. This is more of an observation. Combined with the Niko-Niko and absence of some of the metrics above, now we may be getting an additional dimension that says the team is working sustainably.

Another dimension can be how well the team honors the Retrospective Prime Directive, not only in retrospectives, but also during standard work. If they aren’t casting work in us vs them or treating other external stakeholders with contempt then the team is probably working sustainably.

And lastly, how often does the team celebrate? Do they take time to appreciate each other? These all are indicators of sustainable pace as well.

As you can tell, it’s probably difficult without an excellent Scrum Master/team facilitator, manager, or Coach paying attention to this.

Observing Human Work Systems – A Coaching Fundamental

The topic of observing people working has caught my interest more ever since I attended the Problem Solving Leadership workshop run by Gerald (Jerry) Weinberg and Esther Derby. At this year’s Agile Coach Camp, I ran a session on this to learn more about what other coaches do to see humans at work as well as share areas I know had learned to start paying attention to…

Our first step was to identify behaviors we observe. Some of the more common ones showed up in our list: work artifacts, conflict, movement, body language, noise levels from people and the environment, and patterns of communication between members (who talks to who).  Others are a bit less common: when people take on leadership, where focus is, and what Jerry calls ‘Jiggling’, an interaction or event that gets a system to change in a meaningful direction from being stuck.

I then had a few people volunteer to observe and select what on the system they wanted to observe. The remainder of the people did an exercise I gave them. After, we debriefed what was observed. One person chose to watch people’s body language and with the exercise focused on when people had eye contact. The other chose to watch for who had control of the pen since it was the primary method for getting work done. Lastly, I chose to focus on who took leadership roles at what time.

Comm_Patterns_Mapping

This led to a discussion for understanding how one can observe communications in a meeting and get an idea for who dominates the discussion by drawing lines with who talks to whom and how much. Equal lines with everyone shows little domination while lots of of lines between just a few may show others being ignored. This continued with some discussion around Google’s Project Aristotle and the work of Alex ‘Sandy’ Pentland; here’s a really good paper measuring Face-to-Face communications.

As a follow on, I had the team do a cluster exercise I learned in PSL. I asked the people in the exercise stand next to those with which they most closely worked. This is a very revealing; I’ve done it in a few retrospectives and it can have a team self-reflect on whether they may be isolating others in their work system or if the connections may be wrong to do the work.

We closed by sharing what made observing work systems difficult and how we may be able to improve this important skill. Below is the photo of the flip chart we took about this…

Last ACCUS Session Last Page

It was great seeing the variety of answers for improving our skills as coaches in this domain. Several mentions of humility were made as well as the core Scrum value of Focus. My favorite comment though was the metaphorical answer to “Listen with Your Eyes” and, of course another was one that hints at cognitive empathy, “have multiple views” to remind us of the Elephant and the Blind Men.

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…