Rediscovering the Obvious

…stumbling in the footsteps of greatness

Archive for the ‘Uncategorized’ Category

What did I learn?

without comments

Karl Scotland and I have helped coordinate the organization of the bag stuffing each year for the last three years. It’s a great time because of the awesome group of volunteers showing up and the mindset of “I’m here to learn something while I help out” that’s so pervasive.

The flow of bags was very effective at the end of the day last year and this year we simply started where we left off last year with the same design. Thanks to some great pre-work, we knew where everything was and what needed to go in each bag, so the briefing of the volunteer staff took less than 15 minutes and we were ready to go.

The team got moving and each zone quickly solved any issues that arose, continually improving and adapting how they worked to the needs of their specific area. We got done a couple hours early, and everything pretty much “just worked” better than could be expected.

So, when I’m asked to lead a retrospective, what do I do? Everything went so well, and learning was incorporated so rapidly, that a simple plus/delta seems utterly pointless. The plusses have been amplified, and the deltas have been changed, why should we write them down? So here’s what we did…

We gathered in a standing circle, grabbed a spare piece of swag to use as a talking stick, and each answered one simple question: “What did you learn?”. After sharing, the group reflected the individual’s statement back in a simple phrase appropriate to a sticky note. [1]. As each of us answered, we sat down to bring focus to the people still wanting to speak. Best of all, the “people in charge” [2] did and said very little, and learned quite a bit.

Why did it work? Well, as I mentioned above, many of the volunteers were there to learn. The bag stuffing has filled up in the first volunteer sign-up round (of four) each of the last two years. The process execution was well beyond “good enough”, so it seems like the right thing to do is help people take away more than just their own perspectives. With a majority of volunteers having English as a second (or more!) language, the reflection portion ensured that the individual’s perpective was conveyed clearly and helped to ensure that people were able to absorb the statements effectively. More interestingly to me, the “what did I learn” style questioning seems to have drawn out positive emotions in a way that other retrospective formats haven’t been able to do in my experience.

Here’s to next year!

[1] Karl captured them here.
[2] Specifically, Karl and I as facilitators were able to keep our mouths pretty well shut.

Written by erwilleke

August 22nd, 2011 at 10:57 am

Posted in Uncategorized

Instructional Design Applied to Agile Coaching

without comments

[This is a cross-post from Marian's blog]

Agile coaching requires observant facilitation with an ability to engage learners actively. This parallels almost identically with accelerated adult learning at the university level. “Guide on the side” instead of “sage on the stage” is a common mantra necessary for all effective facilitators to embrace when motivating adult learners. There are scores of interactive instructional strategies that not only provide relevance to the learners, but also allows for quantifiable assessment of the learning growth. However, for this post, I will focus on the instructional design that is the moving force behind effective facilitation effort.

Instructional design is just putting together the course, right?


It is a much more holistic picture of all curriculum/courseware/module, or whatever buzz term you favour. In my experience as the instructional designer for several degree programs at a small university, a huge takeaway has been the understanding of knowing what to standardize and what to customize.

Let’s look at the benefits of instructional design insight for developing multiple training programs or courses of any level.

  • Standardization allows focus on architectural improvements and shared collaboration across coaches.
  • Recreating content for different client contexts is no longer necessary.
  • The modularization of core components allows focus on tailoring courses to specific client needs at a much deeper and more effective level.
  • Everybody shares value and baseline improvements holistically, but can also modularize for personal use. Nobody teaches the same way, and never should courseware force a specific type of instructional methodology.

Any individual coach or organization that trains internally or externally wants a strong relationship with their learners. Internal coaching needs a strong relationship for better and smoother implementation efforts. External coaching needs to consistently improve relationships with their clients beyond the expectations of internal coaching. Another benefit to formalized instructional design techniques being applied to training material is that it improves relationships with the learners in the following ways.

  • Customization is improved for the client’s needed context before and after the course.
  • Coaches can apply beginner’s mind more effectively.
  • Modular pieces allow coaches to make courses more experiential.
  • Familiarity with content and structure allows coaches to breed active learning.

Of course, economics is always a question, even if it’s not the first one. Risk management questions need asked, including, is the cost worth the investment both financially and time-wise. Unfamiliarity with the purpose of instructional design can result in the belief that something so simple is not needed, and just one more step in the process anyway. Let’s look at the economic improvements for course development with instructional design techniques applied.

  • More quality time for coaches is available.
  • Consistent master documents represent a collection of all coach experiences for focused improvement.
  • Course development for a new client is faster with high quality.
  • Course development scales across personal techniques without changing the learning values.
  • Needed improvements are easily targeted.
  • Unnecessary re-invention is eliminated, allowing focused innovation.
  • Easier experimentation content is enabled.
  • Gap analysis is simplified for new course development.

While a book could be written on the value and techniques of instructional design for agile coaching, these are a few ‘down and dirty’ values that instructional design provides for training programs.

Written in collaboration with Marian Willeke

Written by erwilleke

April 28th, 2011 at 11:32 am

Posted in Uncategorized

When teams work differently

without comments

In a few weeks at Rally’s user conference I’ll be leading a session on resolving the problems that arise when different teams have to work together, but have entirely different models for how their work gets completed. Details are posted at

Written by erwilleke

April 20th, 2011 at 11:05 pm

Posted in Uncategorized

More on expand collapse pattern

without comments

There’s a thread on kanbandev today about the role of expand/collapse, and its value in helping to identify the BVI/MMF [1]. Chris’ post, linked above, talks effectively about the ability to discover work that doesn’t need done, as do a couple of Ron’s contributions in the same thread. Unfortunately, from my perspective the language there is still primarily about decomposition of scope, rather than focusing on the real nature of the work we do. The value I find in “expand / collapse” is very different. This learning and discovery is just one of several intertwining aspects important to understanding the nature of the work, but I believe that effective teams are focused on learning and discovery as a matter of course.

Focus the team

One major benefit of expand/collapse is that it focuses more of the team on related tasks. I often joke that at Inkubook we had an MMF WIP limit of 1.1, meaning that there would be one MMF that most of the team was focusing on and one that was just being finished up or just being started. We had a different limit (four most of the time, iirc) for the tasks we broke out of the MMF, and when there weren’t enough valuable tasks left for the MMF that was about to end, people would start on the next one (with the focus being on finishing, not on starting). From what I’ve seen, type of focus scales nicely across teams and planning horizons, allowing “team” and “set of related MMF’s” to be the next unit of abstraction outward. This effectively enables WIP limiting and goal focus at that level. If taken all the way, I should be able to see how my individual activity today rolls all the way up to my company’s True North [2]

Manage Learning in Progress

I spoke on this at the LeanSSC 2010 UK [3] and have been observing the concepts in practice since then. Teams are limited in how fast they can learn, primarily because learning takes research and conversation to achieve [4].  When you apply expand/collapse, keep an eye on the amount of stuff to “figure out” in each broken down item. The ones with lots of stuff to figure out will have the highest variability. I can’t say if you should concentrate it or balance it, or whether you should front-load it or back-load it, but be aware of it as you make your decisions and fit the breakdown to your context. If the process of breaking it out allows you a way to get a BVI without having to figure much out, then by all means defer the stuff that requires lots of figuring out.

Manage abstractions

As I mentioned above in the focus section, the levels of expand/collapse provide a very effective way of managing the abstractions inherent in the work. It’s far easier to have value and prioritization conversations about 5 large items than 50 (or 500) smaller items [5], especially if you’ve managed to effectively engage your senior management in the decision planning. On the other hand, asking a dev team to implement against a single large item taking over a month is pointless, they need the detail to effectively track and deliver against the goals. Visualization of progress against goals is also easier due to the aggregate data, enabling the use of goal-focused reports like a parking lot diagram.

Triggering conversation

The need to apply expand/collapse is also a trigger to figure a bunch of stuff out. The best way to figure things out is to have a conversation about what’s needed with the relevant people. The mere act of decomposition is a value add activity, and should not be done by a single individual. Scrum uses sprint planning and task estimation to drive these conversations, but dropping iterations doesn’t excuse you from the need to explore the meaning of work items and tasks as a group. The conversations need to happen, and the acceptance criteria need to be discovered: “Don’t start what you can’t finish” [6]

Enable Operational Languages

One very nice side-effect of the abstractions in use is that the language used at each level of abstraction can be made appropriate to the audience, and should be. I’ve often heard about deep misunderstandings between “development” and “the business” because the two are speaking completely different languages while using the same words. This is only made more complicated when you introduce other groups as valued stakeholders, such as legal, finance, compliance and operations. With effective expand/collapse and a good goal-oriented organization, the highest levels can be written in terms of markets and the organizational vision, middle levels in terms of the desired behaviors enacted in the market and the protections the organizations require, lower levels in terms of the features that enable those behaviors, and the development level in terms of the actions that need completed to create those features. This is not a problem, this is a positive step to communicate effectively across the organization! [7]

Finally, a perspective

At the lowest level, converting from the most detailed card (task/story/line item/whatever) to code (configuration/html/sql/whatever) is its own expand/collapse translation, and the conversation is one with your compiler and (hopefully) automated tests. There’s no expectation that you can clearly define what code you need when you pick up a task, you’re free to be a professional and add, remove, and modify the code until it solves the need at hand. The same logic should apply to the tasks to complete a story, the stories required to complete an epic, and any other expand/collapse relationship you may have in your particular environment. There are many effective patterns, practices, and guidelines, but the set of actual “rules” is fairly minimal. Do what makes sense, and always strive to be more effective in what you do.

[1]  Business Value Increment, which Chris renamed from Minimum Marketable Feature to clarify it as different than what’s talked about in Software by Numbers

[2] Or whatever you call your organization’s guiding vision for the year/quarter/decade


[4] Dan North tasks about this as removing ignorance in the context of Deliberate Discovery.

[5] I don’t think I’ve seen a Scrum training deck in years that doesn’t have a pyramid diagram for story size indicating the desired backlog composition

[6] Paraphrasing from Alan S, Dean L, and Don R among many others.

[7] I plan on writing shortly about the role of a BA as linguist in this exchange. The post is languishing as a half-finished draft.

Written by erwilleke

February 24th, 2011 at 8:44 pm

Posted in Uncategorized

Away with “Active”

with 3 comments

I dusted off my personal kanban about 45 days ago when I started at Rally, and it’s been a very interesting path since then. When I first rebuilt and updated the contents, the columns were Eventually, Midterm, Nowterm, Active, and Done, and they were essentially prioritization buckets so that I didn’t have to mess around sorting each of the individual items. Roughly mapped to Must Have, Should Have, and Could Have [1].

Last weekend, that changed. I was getting frustrated because I kept having to prioritize things I didn’t really _care_ about, but that I needed to do. It bothered me a lot that I couldn’t get to the stuff I care about, so I updated my columns again. My columns became Options [2], Proactive, Reactive, Active, and Acted. Suddenly I felt much better about things, because I could prioritize the things in Proactive in order of how much I care about them, how engaged I would be, and how distant the payback on my investment of time would be. Reactive, I prioritize based on a combination of ease and cost of delay.

It’s been working, but a pattern quickly emerged that bothered me. Either my active column was empty, or my active column contained the top item moved over my my reactive column. It didn’t tell me anything useful, it didn’t help me prioritize, it was just… there, taking up screen real estate without providing any value. So I zapped it. I don’t have an active column anymore, I just know I’m focused on the top item of one of the two columns that’s in the view. If I’m full of energy and wanting to engage, I hit the top of proactive. If I’m dragging a bit and just want to get some things done, but not pour energy in, I hit the reactive column. When they’re done, they’re dropped into Acted and left to languish with all their finished friends.

[1] Why bother with Won’t have?

[2] Options represents ideas that I don’t want to forget, but don’t have any desire to prioritize or work on now. Approximately weekly I skim that column to see if anything inspires me, but they’re roughly the “transient” class of service.

Written by erwilleke

February 15th, 2011 at 9:46 am

Posted in Uncategorized

Bring your ‘A’ game

without comments

My passion is to engage. I am at my best both personally and professionally when I’m able to confront a situation and engage the people around me. I can then understand the goals they’re trying to achieve, explore the impediments they feel they’re facing, and collaboratively find solutions. Usually, these are not only acceptable to everybody, but exceed the hopes of the individuals. I’ve not only found a solution, I’ve shown people an example that more is possible, and that they shouldn’t have to settle.

That’s my ‘A’ game, and I’m not talking about a grade. I’m talking about the affective learning domain, and how it’s equally important as the cognitive domain [1]. When people talk about being passionate about what they do, they’re talking about having achieved engagement at an emotional level. This engagement is what drives my effectiveness. When I’m engaged, I’m much more capable of understanding the way others are feeling, and I’m able to intuitively match the situation and their concerns against the many mental models I’ve collected over the years. Even better, the people I’m engaged with are more likely to be engaged because they can feed off my engagement. These are the experiences when the most fascinating things happen, the biggest audacious goals are defined, and the world gets changed (at least in small ways).

There’s one big problem, though: It’s fragile. It’s extremely easy to knock a group out of this type of zone. All it takes is one person whining about expenses, or the waitress bringing the wrong beer, or a manager walking into the room with an “We’ve got a problem” look on her face. Please, please, don’t be that guy [2]. Team-level flow is slightly more resilient than individual flow, but it’s less able to ignore the context. As a manager, this is one of your jobs. As a team member, it’s your job too. Ditto ScrumMaster, product owner, and everybody else. Protect your environment, take care of the emotional state of your colleagues, and otherwise design the proper environment for the team to engage without distraction.

[1] Referencing Bloom’s learning domains. There’s also a psychomotor domain that deals with imprinting physical and repetitive behaviors, this is something I should write about after my next code retreat.

[2] Although, there’s not much you can do about last call, really. Learn to stack.

[edit] Forcing a feed update… playing with the blog ;)

Written by erwilleke

January 30th, 2011 at 9:20 pm

Posted in Uncategorized

Just one thing…

with 2 comments

Yesterday, I was reminded of the power of commitment.

I spent the day shadowing Alan Atlas as he helped a room full of managers understand their role in a brave new agile world. At the end of the day I was invited to facilitate the retrospective of the day’s course and attempt to bubble up some of the individual learning to benefit the group. Last night, at the airport, I realized I’ve never written specifically about a powerful technique I’ve added to the end of every retrospective I’ve run over the last year with great effect.

When I’m helping teams reflect, I tend to use a four-stage starfish to structure the thinking process. Yesterday, I tried an ORID model [3] due to there being many individuals rather than a focused team. In the past, I’ve used the six thinking hats to guide the reflective paths, done standard plus/delta, and several other models. [1] Regardless of the retrospective format used, however, there is one thing I always do to close out the exercise: I ask for a commitment.

This is probably the least “nice coach” activity I do as an agile guide. I force members of the group to make commitments. No Weasel Words, no dodges, no non-commitive commitments. I insist on real commitments. “I will set up a meeting next week with Bob, Julie, and Josh to discuss my role as an agile manager.” I don’t accept “I’ll each out to the other managers about this.” I require “I will hang up visible burndowns for each of my three teams” instead of “I’ll start increasing the amount of visual management”. I’m not a nice person. I insist on real, committed language, and I insist it’s something they’re willing to have held accountable by the entire group.


Because it helps. I first observed this while coaching with Simon Bennett in the UK during early summer 2009, and this is where I first heard the term “Weasel Words.” I am amazed at how deeply it struck me about my own behavior, and how much it started focusing my interactions as a coach and team lead. I started doing action plans [2] with individuals and teams. It is one of the things I most appreciate here at Rally: Following through with commitments is part of the company’s core values. Too often, it’s not. Time after time I see teams and individuals make a fuzzy statement of intent and never ever follow through, because the commitment doesn’t _mean_ anything. It doesn’t connect with affective learning, only cognitive learning, and therefore doesn’t stick very well.

As a coach, I force people to connect with what they’re saying. I don’t put individuals on the spot, I put entire groups on the spot. “Stand up, tell your peers what you will _do_, and make that commitment to the group.” Starting yesterday, I even invited (didn’t insist) people to sign the written record of their commitment (i.e. the sticky on the board). It helps create focus when multiple people make very similar commitments.

Just one thing, one pebble, one little piece of progress can start a landslide. It’s even more powerful when you get ten or twenty little pieces of progress. People throughout an organization see many people suddenly DO something and take notice. They instinctively recognize that something important is happening and they watch, and maybe even engage.

[1] I’m more than happy to write about any of these… leave a comment or tweet at me if you’re interested.

[2] Do you want another post on Action Plans?

[3] Scroll down to “The ORID Model” and pay attention to the Kolb Learning Cycle too

Written by erwilleke

January 28th, 2011 at 5:21 pm

Posted in Uncategorized

Welcome to my new home!

with one comment

As many of you know from Twitter and other events, I’ve recently joined Rally as an agile coach, allowing me to engage with a much broader range of teams and contexts as I help guide people towards more effective and satisfying ways of providing meaning and value to their organizations. In the early years of my career, I was lucky in that I was exposed to a great many contexts that often were wildly different from engagement to engagement. As I progressed in my understanding, I began to recognize the value of the perspectives I gained from exploring these different environments. This knowledge allowed me to change my approach to my career, letting me seek out roles and situations that would accelerate this exposure, leading to my explorations of the product development environment as an employee of CSI and later Inkubook. Recognition that Indianapolis was not able to provide the wide exposure I desired led me to take on my role at EMC Consulting, allowing me visibility into many very large organizations over the last eighteen months.

Rally is the next natural step on my path. Coaching with Rally will offer me the continued opportunity to engage with larger companies at the right level to see entire systems and how they work. I’m excited, and I look forward to the stories I will be able to tell, and the ones I won’t…

To those who read this, thank you for your support and guidance over the last 167 posts! This is the new home for Rediscovering the Obvious, and it’s probably very obvious that it’s very much a work in progress. First step is a reasonable theme, then the various plugins and useful things for both myself and visitors. Only then will I start taking the time to try and clean up the older posts, with the expectation that the code blocks will take the most time; I’m hoping styles will take care of the rest of the mess in a reasonable way. Comments are lost, as are my previous view counts (a handful of posts are pushing 1800 views with most posts getting around 500). Thus ends the tale of my conversion from Community Server to WordPress.

Finally, I’d like to offer a very special appreciation to two people.

Michael Ruminer, owner and host of, I appreciate you for making blogging very easy over the last few years.

Bernardo Heynemann, friend and fellow architect over the years, I appreciate you for getting me off my lazy ass 167 posts ago and getting me to put my thoughts on the web. I have gained far more than I ever would have expected, and I owe you.

Written by erwilleke

January 26th, 2011 at 2:32 pm

Posted in Uncategorized

Forgetting yourself in MEF w/ Prism

without comments

Just a quick note in case anybody else runs into this issue in Prism for WPF.

In the code below, the line “return Container.GetExport<Shell>().Value” was failing and telling me with the following message:

System.ComponentModel.Composition.ChangeRejectedException was unhandled Message=The composition remains unchanged. The changes were rejected because of the following error(s): The composition produced a single composition error. The root cause is provided below. Review the CompositionException.Errors property for more detailed information.

1) No valid exports were found that match the constraint

‘((exportDefinition.ContractName == “ABC.DEF.MenuViewModel”)

AndAlso (exportDefinition.Metadata.ContainsKey(“ExportTypeIdentity”)

AndAlso “ABC.DEF.MenuViewModel”.Equals(exportDefinition.Metadata.get_Item(“ExportTypeIdentity”))))’

, invalid exports may have been rejected.

Resulting in: Cannot set import ‘ABC.DEF.Shell.ViewModel (ContractName=”ABC.DEF.MenuViewModel”)’ on part ‘ABC.DEF.Shell’.

Element: ABC.DEF.Shell.ViewModel (ContractName=”ABC.DEF.MenuViewModel”) –>  ABC.DEF.Shell

It turns out, this was for a very simple reason: I’d failed to actually include the line that sets the current assembly as one of the assemblies in the AggregateCatalog. Don’t do that!

    internal class Bootstrapper : MefBootstrapper
        protected override DependencyObject CreateShell()
            return Container.GetExport< Shell >().Value;
        protected override void InitializeShell()
            App.Current.MainWindow = (Window)this.Shell;
        protected override void ConfigureAggregateCatalog()
            AggregateCatalog.Catalogs.Add(new AssemblyCatalog(System.Reflection.Assembly.GetExecutingAssembly()));
            AggregateCatalog.Catalogs.Add(new AssemblyCatalog(typeof(ABC.DEF.Module.ContactModule).Assembly));

Written by erwilleke

December 10th, 2010 at 12:49 am

Posted in Uncategorized

That’s not X!

without comments

Mark Graban has a great post [1] over at Lean Blog today. His overall premise is one we see over and over again in software: People take a good tool, apply it poorly or in the wrong context, and then blame the tool. Worse, they occasionally broadcast their blame, causing people to have a lower reputation of the tool.

In software, this is most recently seen in the certification discussion and in the “Scrum vs. kanban” conversation. As a result, I very much want to call out a couple of things Mark says in the healthcare context that apply equally well in the software context:

But the difference I draw from the Lean critics:

  1. They see L.A.M.E. and leap to the conclusion that Lean is inherently bad. They throw Lean under the bus and take the tone that these leaders are “idiots.”
  2. I see that Lean works well when leaders learn about and embrace the full management system. I work to try to educate healthcare leaders who are smart, but have a different viewpoint on management.

This is absolutely what I see with agile, lean, scrum, and kanban quite frequently. Teams try, fail, and blame the tool. Yes, it’s quite possible the team tried the wrong tool. It’s also quite possible they didn’t actually use the tool the way it was intended. [2] It could be their context is wrong for that tool in the first place, or that they changed their labels but didn’t change anything they actually do, or that they did things right but ran into a management wall, or faced struggles scaling out to other teams, or any of the hundreds of other reasons that adoptions “fail”.

We amplify this with the way our labels and language creates lines rather than identifying a body of perspectives and tools. It’s time to take a cue from BDD and define some scenarios and well-formed outcomes of the adoption. Mark presents a great list from a nursing perspective…

Why would nurses WANT Lean? When organizations really embrace Lean:

  1. Nurses say, “Finally! Management is seeing the problems we face every day and we’re going to work together on fixing things.” Instead of feeling neglected, they are being properly supported and involved in process improvement.
  2. The culture changes to fix routine “Every Day” problems – instead of jumping through hoops and constantly fighting the same fires, they get to focus more time on patient care.
  3. Lean helps support save care – proven documented examples include reduced patient falls, fewer infections, and fewer cases of V.A.P. — nurses want the best for their patients.
  4. With Lean, the space is designed and sized to match the processes for nursing care, instead of nurses being forced into spaces that don’t have enough bed/equipment storage space, for example.
  5. They get to design their own standardized work and can improve it through daily huddles and kaizen boards.
  6. The nurses get to work as part of a team (such as ThedaCare’s Collaborative Care model, where the RN helps direct doctors and pharmacists.
  7. Nurses work less overtime because they have more time during the day to do proper charting instead of batching it at the end of the day.

These sure feel like things I can see and validate against when they happen. What’s our list look like for software? Here’s a few that come to mind immediately:

  • When a stakeholder asks for a release, it’s done quickly, easily, and with a minimum of fuss.
  • When a stakeholder identifies an opportunity related to the current application [3], it’s not painful to make it into reality.
  • When a problem is discovered with the app, it’s professionally and quickly fixed without attacks or defensiveness.
  • Simple and appropriate improvements are accepted and implemented with a minimum of fuss regardless of source.
  • Teams work in ways that suit them while still respecting their organization
  • People go home, have families, and maintain good balance despite loving their jobs
  • People care about the end result, not just their own specific job
  • Individuals are respectful across specializations, and attempt to use a shared language and goals rather than engaging in “legalese” or “geekspeak”.

What else?

[1] All quotes attributed to “Mark” are from this post, used with permission:

[2] Personally, this is where I stop because I feel like I’m approaching the “If it works, it’s Scrum, if it doesn’t, you did it wrong” perspective, but that’s not useful, so I’ll continue.

[3] Using “application” as shorthand for “software stuff we build” including systems, services, apps, etc.

Written by erwilleke

November 9th, 2010 at 4:00 pm

Posted in Uncategorized