Skip to content


Growing Up

Portia Tung - Selfish Programming - Sat, 09/05/2015 - 20:50

Birthday Baby

A New Season’s Greetings

September has always been a special month for me. It’s a month of new beginnings, ranging from the start of a new season to that of a new school year, throbbing with the promise of excitement and adventure.

September is also the month of my birthday and I’ve had to make special preparations this year given I’m about to turn 40. The big 4-0. And I think this impending event has blown a circuit or two in my head.

Birthday Baby

Looking back, I now realise I not only suffered from acute thrisis (mid-life crisis in my thirties), I also had a similar short-circuiting experience just before I turned 20. And it turns out I’m not alone.

According to one theory about “9-Enders“, people who’s current age ends in a “9” such as “19”, “29”, “39”, “49”, 9-Enders find themselves searching for answers to the big questions: “What is the meaning of life? What is my purpose? What does it mean to be happy? What makes me happy? What’s my life plan?”

What’s more, research shows that most people respond in one of two ways when confronted by such questions. One group will become more determined to make the most of their life while the other group concludes that “my life sucks” and grows increasingly despondent.

Becoming Better with Age

Just as September marks the end of something old, September marks the start of something new. So long as we continue to stretch ourselves by expanding our comfort zone, we can keep going strong.

If you’ve become unstuck with the big questions or even small ones, or simply want to feel re-energised and inspired to get a move on with your dreams, join my friends and I in a bunch of fun-packed and thought-provoking conference sessions in the UK this autumn:

Agile Cambridge: 30 September, Cambridge, UK.

Agile Tour London: 23 October, London, UK.

Categories: Blogs

Does Your Culture Require Your Demise? Pig & Chicken 3 [Agile Safari]

Agile For All - Bob Hartman - Thu, 09/03/2015 - 23:24


Tweet the Agile Safari Cartoon!

Pig & Chicken Part 3 is about the bigger picture. It is about the culture of your organization and about memes that exist within that culture. Beyond just delivering a ranked list of “stuff”, can you commit to being your best self each day?  What does it mean for YOU to commit to the organization? What is expected of you? What do you expect from each other? I’m not just talking tangibly… what does expectation feel like where you work? Is it sustainable?

Recap: Pig & Chicken Part 1 is about letting teams focus and figure out how to do the work. Pig & Chicken Part 1 (the ‘classic’) the pigs are supposed to represent the team and the chickens are supposed to be “everyone else.” In the past, some people compared the chickens to management, and it led to people saying “we have to keep the chickens out” (and much worse). Pig & Chicken Part 2 is about being all in as an organization, so everyone is in sync with the top priorities of learning and delivering value. In Pig & Chicken Part 2, we are either all in this thing together or we aren’t — make a choice and decide what organizational commitment means. 

We Commit All the Time

Commitment is a big word in agile and life in general. We commit in personal relationships. We commit to family and friends. We commit at work. We commit all the time, frequently without thinking about it much. When we commit at work, it frequently happens without thinking about it.

  • We have “official” commitments where people commit to getting a bunch of work done by a date.
  • We have estimates about when features will be done, which become commitments in many cases.
  • We commit to each other all the time both formally and informally.
  • In agile we are supposed to commit to things (yes, even if you say forecast).

Take 30 seconds and think of one or two commitments that you have made. Are you all just marching to the beat of some meme that has been there “forever?” Are you committed in an irresponsible way? Do you and others even realize it? Are there memes or currents that are pulling you away from shore?

What Does Commitment Mean at Amazon?

The current pile of articles and discussions about Amazon caught my attention and while this article is not intended to be about Amazon, there were a lot of tie-ins. For those of you who have not been sucked into this story, I see a lot of relevance with this idea of culture and memes.  I’ll point you to some articles, in case you want more info, but here is my short version…

  1. It “started” with the article (by Jodi Kantor and David Streitfeld) in the NY Times titled “Inside Amazon: Wrestling Big Ideas in a Bruising Workplace.” Among other ideas (e.g. toil long and late, sabotage each other, etc.), the one that Amazon just cuts the bottom ranked performers each year seemed odd, at least to me. This reminded me of the old GE approach of cutting the bottom 10%. The premise was that if everyone is ranked on a bell curve and you have some so called A players and some so called F players, you cut the F players and you are in better shape. It seems logical. However, this is heavily dependent on how people are ranked and on ranking people individually. It also presumes that some portion of your people suck. So IF you hire awesome people, are you okay firing the least awesome percentage of them? It can also create a system where individuals are competing against each other, at the expense of effectiveness. Finally, it does not seem to jive with Amazon’s principle No. 5: “Hire and Develop the Best.” If you are just cutting the so-called bottom and they are awesome, that seems like you have issues with your leadership. If people are not “the best” yet, don’t you have to also look at your leadership, since they are not helping people develop? Obviously, I don’t work there, so maybe this is going on, but reading story after story (and there are thousands of comments on these and other articles), at a minimum, leadership has some responsibility!
  2. So was the story true? An Amazon employee posted an article on LinkedIn refuting it (in his experience). The NY Times responded to him and other criticism with a clear, and to the point assessment of the article. Ultimately, the initial story seems to hold up.
  3. In yet another article (by David Streitfeld and Jodi Kantor) titled “Jeff Bezos and Amazon Employees Join Debate Over Its Culture,” They include some excerpts from Mr. Bezos to employees, where he told workers “I don’t recognize this Amazon and I very much hope you don’t either.” I read that as ‘this is not the culture I know at Amazon.’ And, in a letter to employees, Bezos states that Amazon would not tolerate the “shockingly callous management practices” described in the article. He urged any employees who knew of “stories like those reported” to contact him directly. Even if it’s rare or isolated, our tolerance for any such lack of empathy needs to be zero.” {my emphasis}  This last sentence really struck me. This does not appear to be a guy who is playing around. This does not appear to be someone ducking the issue.
  4. Finally, in “Work Policies May Be Kinder, But Brutal Competition Isn’t” Noam Scheiber points out that “The account appeared to put Amazon at odds with recent workplace trends, but the reality experts say, is not nearly so neat: Grueling competition remains perhaps the defining feature of the upper echelon in today’s white-collar workplace.

Amazon is a large company, with 180,000 employees. There does not seem to be a belief that these stories are false. So how does it come to be that this kind of thing can happen in an organization like Amazon. I can understand it at a company with a CEO who would never ever consider making some of the statements that Mr. Bezos does (e.g. Even if it’s rare or isolated, our tolerance for any such lack of empathy needs to be zero.”) But for a company that has a CEO like him, how did it get that far?

When Did Commitment Have to Mean Your Demise?

If you work at an organization where the culture is leading to your demise, at what point do you have to make a choice? Or are you just trapped there? If you are a manager at one of those organizations – what is it like for you? Are you okay with that type of organization? Even everyone is in agreement (like in the second panel of the cartoon), does that make it right? Part of this is the culture of “being busy.” Does that actually work? We know that working 70 hours a week does not produce better results (“The Research Is Clear: Long Hours Backfire for People and for Companies). I’ve personally been struggling to write. I realized that I need a lot of slack for my brain to reach that point where writing flows. A lot more than I thought. When I’m traveling a lot, I am just not in that space where the ideas flow and connect in a way that I’m happy with. I can certainly blast out a few pages of thoughts, but it does meet my quality standards!

Y’all are so busy being busy you aren’t getting anything done!” — Peter Saddington

Bring in the Hero!

Talking with Allison Pollard on this topic, she pointed out the craziness of needing a hero or heroics in every sprint. Do you want to be a hero? Is the whole team heroes? Do you wear costumes like these people?

#Agile2015 this will be interesting! Superhero party…

— Jake Calabrese (@jcalabrese) August 6, 2015

I’ve been the hero.  I’ve saved the day. I’ve worked on major holidays. I’ve stayed up all night to fix problems in a code base or with down data lines. I’ve watched a lot of others do it as well. I HAD TO! Who else could do it? Or at least that was the story I told myself. I’ve gotten exhausted by it. I’ve watched others burn out or worse destroy their health or their personal lives. And sure, there are situations where that is required. They are real and at least some of the ones I’ve experienced were like that.  Yes I’ll work all night so that the stores can open on time and help the customers.  But it is a very slippery slope.

This bullshit about constantly saying “well… we just have to get through ‘this one thing'”, is absurd!

Sustainable Pace

The cartoon points out the insanity of how often we fall into a culture or a meme where we will sacrifice almost anything and often ourselves. Sure, I have not heard anyone actually say “team, we are going to put so much into this effort that we are literally not going to be around for the results.” But, in practice I see people doing this all the time. This is not a sustainable pace. I’ll say it again, this is not a sustainable pace!

How is serving yourself up on a plate sustainable?!?

Perhaps you should consider some changes if you are effectively destroying yourself to deliver. Mike Vizdos says “Focus. Deliver.” I like that! But he would never say “Focus. Destroy Yourself. Deliver Yourself on a plate!” How the hell would that make any sense? How does “Deliver Once” make any sense???! It’s sad. And it’s not helpful in the medium or long term…  Likely not even in the short term! What culture do you actually have? There is the one you want and the one that exists. There are memes within that culture. How are you staying aware and engaged enough to know? If your organization’s plan is to thrive or survive by ‘taking out’ it’s employees one project, weekend, or evening at a time — It may be time to get some help and make some changes!!

Tweet the Agile Safari Cartoon!

Subscribe to receive emails with my new posts and Agile Safari cartoons and Follow me on Twitter or Google+ to stay in touch!

The post Does Your Culture Require Your Demise? Pig & Chicken 3 [Agile Safari] appeared first on Agile For All.

Categories: Blogs

Are we tabby cats trying to emulate cheetahs?

AvailAgility - Karl Scotland - Thu, 09/03/2015 - 19:30

Credit: Dennis Church

Credit for the title of this post goes to Sam Murphy, Section Editor at Runners World UK. Those of you who have seen me recently we will probably know that as well as being an advocate of Lean and Agile, I also have a passion for running, and I subscribe to Runners World. Sam used this title for an article of hers in the September issue, which struck me as having lots of overlaps with how I go about coaching and consulting in businesses. The gist of it was that when training, rather than trying to copy what elite athletes do, we should find out what works for ourselves. Sound familiar?

Here’s some quotes:

Dr Andy Franklyn Miller … concluded that ‘a very unique and customised strategy is used by each swimmer to excel’. And if that’s the case, is looking at what the elites are doing and aiming to replicate it the best way to maximise our own sporting success? Or are we tabby cats trying to emulate cheetahs?

Is a very unique and customised strategy used by each successful organisation to excel? Is looking at what these organisations are doing and aiming to replicate it the best way to achieve success? Or are we tabby cats trying to emulate cheetahs?

Dr George Sheehan, runner and philosopher, said “We are all an experiment of one.’


Ultra runner Dean Karnazes … writes “I always encourage people to try new things and experiment to find what works best for them.’

It seems athletic training is not so dissimilar to building a successful organisation! Rather than just copying what we may have seen or read about working elsewhere, we should encourage organisations to try new things and be experiments of one. That’s what Strategy Deployment is all about!

Or (to close with the same quote Sam closed her article with) as Karnazes also said:

‘Listen to everyone, follow no-one.’

Categories: Blogs

New Case Study: Medical Technology Leader Leverages SAFe to Free Teams from Silos, Align the Enterprise

Agile Product Owner - Thu, 09/03/2015 - 16:14

elektaWhen we learn about companies like Elekta who are in the very serious business of improving the lives of people facing cancer or brain disorders, we are inspired. And when we heard that they had adopted SAFe and wanted to share their story, we were excited to hear about their experience.

As one of the world’s leading medical technology innovators, Elekta provides solutions that touch over 100,000 patients a day worldwide. Headquartered in Stockholm, they employ around 3,800 employees globally in 30 countries. With teams working in several time zones, and members having different backgrounds, their challenge was to create an environment where teams could better align with global priorities and with each other.

Several years ago they turned to Scrum, but in their attempt to scale up they saw that the teams were operating in silos, which created a host of issues with dependency, integration, visibility, and alignment throughout the enterprise. Wanting to address all areas of the enterprise, Elekta took a holistic view and introduced SAFe to their Scrum teams, launching their first Agile Release Train (ART) in 2013. Soon thereafter, they expanded to the Program level and trained all of their teams.

Today, Elekta is running 4 ARTs with 20 teams across three continents. Their SAFe journey continues, and has already delivered significant gains and improvements in several areas. There’s a lot to learn from Elekta’s experience, which they’ve summarized in a PowerPoint, including some great speaker notes.

You can view the Elekta study here

Many thanks to Elekta’s Director of Engineering, Petrine Herbai, Manager of Engineering, Lars Gusch, and our Gold Partner, Rally Software; we appreciate all the great information you have shared, and look forward to hearing more about your continuing journey of transformation.

Stay SAFe!

Categories: Blogs

Agile Workshops at the first Agile Greece Summit

Ben Linders - Thu, 09/03/2015 - 14:52
I will be giving two workshops at the Agile Greece Summit in September, on Valuable Agile Retrospectives and Getting More out of Agile and Lean. There are still some tickets available, book your seat now! Continue reading →
Categories: Blogs

Scrum as an agent of culture change part 2

Agile For All - Bob Hartman - Thu, 09/03/2015 - 05:23

In part one of this series, we defined culture. We also described why it is both critical and hard to work on. Finally, we left you with a teaser that there is a pretty good pattern we’ve seen for how to kind of hack your culture for the better. 

Scrum as a Culture Change Agent

I have seen a pattern emerge at several organizations where I’ve worked or coached. A team starts using Scrum. When they use it effectively, they start to think differently about the way they work. They build different social structures. They value different outcomes. They alter decision making structures. And the culture starts to change. We are rewarding different behavior, at least for that team. If they can stick with it long enough to solidify the new set of behaviors, the culture change lasts. When those teams are successful, other teams in the organization start wondering what they’re up to. They learn about scrum, try it out, and if they do it purposefully, the pattern repeats itself. Scrum becomes an organizational change agent.Scrum-Culture-SpreadScrum is based on a cultural mindset that is often different from the existing cultures where it is introduced. In my experience, there are at least four specific characteristics of scrum that help it to spread within an organization: Quality, Value, Team Focus, and Trust. Below, we take a quick look at each of these aspects of Scrum, describe why each matters to the key stakeholders in any effort, and how it helps to spread a new cultural mindset with its related behavior patterns.

Using Scrum to Improve Quality

The Adobe Audition teams started using Scrum in 2005, and I acted as the ScrumMaster. Our goal was to get to releasable quality each four week sprint throughout the course of an 18 month release. While Scrum felt much better to the team, some people in our organization asked if we had any hard data. That’s tough to get, since many of the things we would have tracked prior to using scrum didn’t make sense to track anymore. One exception was the total number of open bugs at any given point. I created a graph showing the total number of open bugs over time for the previous release compared to the most recent release using scrum:

The graph shows that we had 33% of the open bugs at the peak compared to our previous release. Of course the real measure of quality was in the response from users, who consistently rated the product highly on ease of use and reliability. We had customers that trusted it enough to use very early “pre-release” builds for real audio production work, where errors and usability would have cost them time and money.

The graph had a big impact on other teams. When they saw that we had kept our bug count so low, they got curious. They became even more interested when, during the “end game”, the last few months prior to the big release, our team was out playing whiffle ball on the lawn while they were in full-on crisis mode trying to get their products ready for release, working nights and weekends.

Stakeholder Benefits of Improved Quality
  • Employees have a stronger sense of satisfaction in their work. Nobody wants to build a shoddy product – scrum tends to give teams permission to do the right thing even in the face of pressure to go faster.
  • Customers are more satisfied with the product and can provide better feedback on the actual features rather than just defects, leading to stronger adoption and higher loyalty.
  • Executives get higher revenue at a lower cost. There is strong anecdotal evidence that quality issues become significantly more expensive to fix the longer we wait. Scrum’s focus on getting to releasable quality every sprint leads to a lower overall cost to build the product. The higher customer satisfaction leads to greater adoption and revenue.
  • Shareholders get higher ROI as the organization improves, leading to higher valuation of the company.
Cultural Impact of Improved Quality

Almost every company says that it values quality. Scrum gives a simple rule that helps to enforce it: get releasable every sprint. When teams follow this rule, “quality is the top priority” often shifts from something that we say but don’t follow through on to the reality of our everyday work. When quality is valued, people also take more pride in their work. There are no longer any cultural barriers to doing the right thing. People start to trust that there is alignment between what we say and what we do. This leads to increased trust between management and employees as well as higher engagement all around.

Higher quality also results in fewer crises. In the example of the Audition team, it helped us reinforce the value of working at a sustainable pace. No extra hours were required.  This experience led directly to three other product teams adopting scrum for their next releases.

Using Scrum to Deliver Value Quickly and Continuously

In a traditional project, we invest money over time, and don’t deliver any real value to the business or users until the whole thing is wrapped up and delivered. On a Scrum project, we can deliver value almost immediately, and then again after each sprint. This approach is great for getting early technical and user feedback, but it also makes great economic sense. Let’s look at the difference between a traditional six month project and one using scrum.Value Delivery Scrum vs Traditional

Teams using Scrum begin delivering value to customers after just a few weeks, accumulating value throughout the remainder of the project and beyond. Teams using a traditional approach deliver no value until the overall project is complete. This creates gaps both in time to market and accumulated value over time. Finally, the traditional project is accumulating risk and sunk cost that is much greater than that of the scrum team. Notice the gap between the red (cost) line and the blue (traditional value) line. The growing gap represents investment with no return, which is correlated directly with business risk.

Stakeholder Benefits of Improved Value Delivery
  • Employees get a much tighter feedback loop with customers, leading to stronger awareness of what problems are most important to solve, and to seeing their solutions actually make a difference for their customers. Empathy for user’s problems is a key determinant in the success of any product or service. Theresa Amabile found that the highest predictor of engagement is “small wins“. Early value delivery connects the team directly to multiple small wins.
  • Customers get their problems solved much earlier, and can provide feedback along the way. They don’t have to wait months or years for the highest priority solutions to be delivered.
  • Executives are measured and compensated based on their ability to increase shareholder value, which means they need to deliver as much value as early as possible at the lowest cost possible. Scrum helps executives meet this goal, making both them and their shareholders happy.
  • Shareholders love the improved time to market and better product/market fit based on early feedback. They also benefit from decreasing risk and opportunity cost by increasing revenue over the course of the development effort, rather than waiting until a big bang release.
Cultural Impact of Improved Value Delivery

Scrum is often descried as an empirical framework, meaning that it provides transparency with frequent opportunities to inspect and adapt. Delivering working products and services early creates a cultural shift from predicting to testing hypotheses in the market. This shift to an empirical approach significantly reduces power imbalance between the managers and the teams. It creates a new mindset of “let’s try it out and see what we learn”, rather than a mindset of “I made this prediction, you’d better make it happen”.

Using Scrum to Create Team Focus

Traditional organizations tend to structure around areas of expertise. For a software organization, this might mean that all of the coders have one boss, the testers a different boss, the product managers a different one, etc. These different silos of expertise then need to coordinate their efforts to deliver value. This silo approach also tends to result in a focus on improving a single piece of the value stream over optimizing the flow of value through the value stream. Coders focus on churning out more code faster, testers focus on executing more and better tests, etc. This can lead to queues of work between the stages of development, something that we know from Theory of Constraints and Lean Thinking (see a nice comparison of the two here) will lead to quality problems, slower delivery, more difficulty adapting to change, and higher frustration as an

From a social standpoint, the traditional approach tends to create teams of similar experts, who work together to get better at their area of expertise, but often end up working in isolation on their piece of the puzzle. Scrum focuses on creating cross-functional teams made up of experts in all of the different areas required to deliver value. This shift to cross-functionality then shifts the focus from “improve my area” to “improve our ability to deliver value”. The entire focus of the team switches to a broader perspective, and in my experience, this leads to a more rewarding outcome. After all, if I got into computer programming, I probably did it because I loved solving interesting problems in a way that made someone’s life easier. Scrum re-connects the work I do writing code to how it solves a customer’s problem.

This shift in focus from “me” to “team” also asks people to work on their social connections in a way that the “throw on the headphones and code away on my assigned task” approach doesn’t. Social Connection is critical to a healthy, happy life. Recent studies in neuroscience, psychiatry, and psychology are showing that humans are meant to be social, that it creates resilience to stress, resistance to addiction, and higher life satisfaction in general. Scrum teams learn to balance the need for individuals to get into flow states with the need to keep connected to each other.

A recent study confirmed what many team experts have been teaching for decades: effective teams voice and work through differing opinions about how to get work done, but do so in a way that focuses on the problem to be solved, not the people solving the problem. Scrum tends to emphasize this approach, leading to higher engagement, team satisfaction, and better business results.

Stakeholder Benefits of Improved Team Focus
  • Employees get stronger connection to each other and to how their work affects customers and users, resulting in higher engagement and job satisfaction.
  • Customers get better results from teams focused on delivering value to them, rather than getting better at their area of expertise.
  • Executives benefit from higher engagement of their people, higher retention, and higher customer satisfaction.
  • Shareholders benefit in the same way as executives.
Cultural Impact of Improved Team Focus

Shifting the focus from “me” to “we” is a key cultural benefit of scrum. No longer are we solitary heroes or zeroes, but engaged members of teams focused on delivering value to customers.

Using Scrum to Build Trust

When teams regularly deliver value, sprint after sprint, the traditional “plan and control” efforts become superfluous.

  • We no longer need weekly status reports to make sure things are on track, we simply go to the sprint review and see what the team has built.
  • We no long try to shift “resources” around to deal with the crisis-du-jour, we simply pass urgent needs on to a stable team, whose process is built to address such work.
  • As teams build the technical infrastructure to do automated testing and continuous integration, we trust that we can change plans whenever we discover a more important need.
  • As teams work together, inspecting and adapting their process to improve value delivery, they build trust amongst each other that they’re all in it for the same shared purpose, and will contribute wholly to the effort.

The net result of all of this is trust, perhaps the most powerful catalyst of cultural change.


Trust allows people to feel safe trying something new. Maybe it will work, maybe it won’t, but with trust, we’re willing to give it a shot. The fear of failure is mitigated. Without the willingness to experiment with new ideas, behaviors, and processes, we are simply allowing water to flow down the same path as always. We need to dig a little canal, maybe dam up another area, throw some rocks in another – something to see if we can find a better way to deliver value.

We want our culture to exhibit what author Nassim Taleb calls “antifragile” characteristics; that is, the culture improves in the presence of stress and change, rather than breaking (fragile), resisting (robust), or flexing for a moment only to return back to normal (resilient). If we aren’t experimenting, we are not improving, and scrum is built to experiment and build the trust required to try new things. It’s one of the few reliable patterns I’ve seen for creating lasting cultural change in an organization.

Want Help?

If you are interested in trying this out in your organization, Agile For All has helped hundreds of organizations implement scrum as a first step to improving the overall work culture, helping leaders balance culture and strategy. Feel free to contact us, or email me directly at to learn more about how we can help!

The post Scrum as an agent of culture change part 2 appeared first on Agile For All.

Categories: Blogs

How to Know if TDD is Working

Powers of Two - Rob Myers - Thu, 09/03/2015 - 03:10
How will you know if TDD is working for your teams, program, or organization?

I've noticed that small, independent teams typically don't ask this.  They are so close to the end-points of their value-stream that they can sense whether a new discipline is helping or hindering.

But on larger programs with multiple teams, or a big "roll-out" or "push" for quality practices, leaders want to know whether or not they're getting a return on investment.  Sometimes they ask me, point-blank: "How long before I recoup the cost of your TDD training and coaching?" There are a lot of variables, of course; and knowing when you've reached break-even is going to depend on what you've already been measuring.  Frankly, you're not going to be able to measure the change in a metric you're not already measuring.  Nevertheless, you may be able to tell simply by the morale on the teams. In my experience, there's always a direct correlation between happy employees and happy customers. Also, a direct correlation between happy customers and happy stakeholders.  That's the triple-win:  What's truly good for customers and employees is good for stakeholders.

So I've assembled a few notes about quality metrics.

Metrics I like
(Disclaimer: I may have my "lead" and "cycle" terminology muddled a little.  If so I apologize. Please focus on the simplicity of these metrics.  I'll fix this post as time allows.)

Here are some metrics I've recommended in the past.  I'm not suggesting you must track all of these.
  • Average lead time for defect repair: Measure the time between defect-found and defect-fixed, by collecting the dates of these events.  Graph the average over time.
  • Average cycle time for defect repair: Measure the time between decide-to-fix-defect and defect-fixedby collecting the dates of these events. Graph the average over time.
  • A simple count of unfixed, truly high-priority defects.  Show-stoppers and criticals, that sort of thing.  Graph the count over time.
Eventually, other quality metrics could be used.  Once a team is doing well, Mean Time Between Failures (MTBF), which assumes a very short (near-zero) defect lead time, can be used.

On one high-performing team I worked on way back in 2001, we eventually focused on one metric:  "Age of Oldest Defect."  It really got us to dig into one old, ornery, hard-to-reproduce defect with a ridiculously simple work-around (i.e., "Please take a deep breath and resubmit your request" usually did the trick, which explains why we weren't compelled to fix it for quite some time).  This bug was a great representation of the general rule of bug-fixing:  Most bugs are easy to fix once found, but very difficult to locate!  (Shout out to Al Shalloway of Net Objectives for teaching me that one.)

I also suggest that all teams keep an eye on this one:  Average cycle &/or lead times for User Stories, or Minimal Marketable Features. On the surface, this sounds like a performance metric.  I suppose if the work-items are surely arriving in a most-important-thing-first order, then it's a reasonable proxy for "performance."  But its real purpose is to help diagnose and resolve systemic (i.e., "process") issues.

What’s truly important about measuring these:
  1. Start measuring as soon as possible, preferably gaining some idea of what things look like before making broad changes, e.g., before I deliver my Essential Test-Driven Development course, and follow-on TDD coaching, to your teams.
  2. The data should be collected as easily as possible: Automatically, or by an unobtrusive, non-managerial, third party. Burdening the team with a lot of measurement overhead is often counterproductive:  The measurement data suffers, productivity suffers, morale suffers.  
  3. The metrics must be used as "informational" and not "motivational": They should be available to team, first and foremost, so that team can watch for trends. Metrics must never be used to reward or punish the team, or to pit teams within the same program or organization against each other. 
If you want (or already have) highly-competitive teams, then consider estimating Cost of Delay and CoD/Duration (aka CD3, estimated by all involved "levels" and "functions"), customer conversions, customer satisfaction, and other Lean Startup metrics; and have your whole organization compete against itself to improve the throughput of real value, and compete against your actual competitors.

A graph sent (unsolicited) to me from one client. Yeah, it'd be great if they had added a "value" line. Did I mention unsolicited? Anyway, there's the obvious benefit of fewer defects.  Also note that bugs-found is no longer oscillating at release boundaries. Oscillation is what a system does before tearing itself apart.Metrics I didn't mentionVelocity:Estimation of story points and the use of velocity may be necessary on a team where the User Stories vary considerably in size.  Velocity is an important planning tool that gives the team an idea of whether the scope they have outlined in the release plan will be completed by the release date.

Story points and velocity (SPs/sprint) give information similar to cycle time, just inverted.

To illustrate this:  Often Scrum teams who stop using sprints and release plans in favor of continuous flow will switch from story points per sprint to average cycle time per story point. Then, if the variation in User Story effort diminishes, they can drop points entirely and measure average cycle time per story.

The problem with using velocity as a metric to track improvements (e.g., the use of TDD) is this:  As things improve, story-point estimates (an estimate of effort, not time) may actually drop for similar stories.  We expect velocity to stabilize, not increase, over time.  Velocity is for planning; it's a poor proxy for productivity.
Code coverage:You could measure code-coverage, how much of the code is exercised via tests, particularly unit-tests, and watch the trends, similar to the graph above (they measured number-of-tests).  This is fine, again, if used as an informational metric and not a motivational metric.  Keep in mind that it's easy for an informational metric to be perceived as motivational, which makes it motivational.  The trouble with code-coverage is that it is too much in the hands of those who feel motivated to improve it, and they may subconsciously "game" the metric.

About 10 years ago, I was working with a team who had been given the task of increasing their coverage by 10% each iteration.  When I got there, they were at 80%, and very pleased with themselves.  But as I looked at the tests, I saw a pattern:  No assertions (aka expectations)!  In other words, the tests literally exercised the code but didn't test anything.  When I asked the developers, they looked me in the eyes, straight-faces, and said, "Well, if the code doesn't throw an exception, it's working."

Of course, these junior developers soon understood otherwise, and many went on to do great things in their careers. But they really did think, at the time, they were correctly doing what was required!

The metrics that I do recommend are more difficult to "game" by an individual working alone.  Cycle-times are a team metric.  (Yes, it's possible a team could conspire to game those metrics, but they would have to do so consciously, and nefariously.  If you don't, or can't, trust your team to behave as professionals, no metric or engineering practice is going to help anyway.  You will simply fail to produce anything of value.)

Please always remember:  You get what you measure!

Categories: Blogs

Framing the Question

George Dinwiddie’s blog - Thu, 09/03/2015 - 02:25

“I need this project done by date D and within cost budget C. Now calculate an estimate on the project.”

A friend of mine used this example to illustrate anchoring bias in estimation. Note, however, that he doesn’t make the question explicit. Further conversation revealed that he had in mind that the date and cost should be the output of the estimation. With that assumption, that statement preceding the request will definitely anchor the answer, and realizing that this bias is likely will call into question whatever estimate is given.

Given the stated need, however, I would reframe the call for an estimate from “When will this project be done and how much will it cost” to “What is the likelihood that the project can be done within these constraints?” When the time and money constraints are already known, it’s somewhat disingenuous to ask that these values be estimated. If the estimate exceeds the budget, then it’s likely that a negotiation will follow. Such a negotiation helps bring the estimate in line with the budget, but generally does little to bring the actual costs in line.

Reframing the question is much more helpful. It should provoke a response along the lines of “We feel 80% confident that we can meet the time and money budget based on these assumptions…. We have identified … as risks that would endanger meeting the budget and which should be monitored closely. Another possibility is that the response is of the form “There is a 10% chance that this project can be accomplished within the time and money constraints. If you’d like, we can explore finding a subset of the project that has a higher likelihood of completion but still have value.”

Either of these answers is more useful for the person with the budget who wants to decide whether to invest in the project or not. Sometimes the best outcome for a project is to kill it before starting when it’s unlikely to result in a happy conclusion. Other times we know to proceed cautiously, and can keep an eye on variables that will indicate whether we’re on a path to success or failure given the stated constraints. We should have alternate plans that we can turn to in the event that one or more of the risks materialize.

Such an estimate doesn’t guarantee success, but it does give us a feel for the merits of pursuing the endeavor. The associated assumptions and risks provide information to help us understand whether or not we’re still on track. This probabilistic estimate is much more helpful than is an estimate of the values.

Not all situations benefit from an estimate of the probabilities. We should think about what sort of answer would really help us, and ask the question that will produce an answer of that sort. Asking for “an estimate” without knowing and communicating the form of answer that will be useful is unlikely to give us appropriate information.


Categories: Blogs

Call for GOAT15 Speakers

Notes from a Tool User - Mark Levison - Wed, 09/02/2015 - 22:05

Gatineau-Ottawa Agile Tour 2015The Call for Presentations for GOAT 15 has just opened. The 2015 edition of the Gatineau-Ottawa Agile Tour, affectionately known as GOAT, will take place on November 23rd, and be a value-packed conference for the 300+ professionals expected to attend this year.

Would you like to present a case study or a report on your experience implementing Lean or Agile within your business or workplace? Have you discovered a workshop so useful that you would like to share it with others? Would you like to take the opportunity to share your knowledge on Lean or Agile? If yes, Agile Ottawa organizers would love to hear what you have to offer.

Submit your presentation ideas at Deadline for submissions is September 30.

Categories: Blogs

New download – SAFe in 8 Pictures

Agile Product Owner - Wed, 09/02/2015 - 15:13

Hello everyone,

SAFe Foundations has been the cornerstone PowerPoint presentation for you to introduce the Scaled Agile Framework in your enterprise. Now there is a new, lightweight tool for introducing: (1) the levels, (2) the people, (3) the backlogs, (4) the cadence, (5) code quality, (6) relentless improvement, (7) economic prioritization, and (8) the full Big Picture.

The idea for this deck came about last year when I was presenting SAFe to an executive team. Three slides into my 35-slide deck, they asked me to turn off the projector. Standing in front of a 3 x 5 foot image of the Big Picture, we spent the remaining two hours discussing different dimensions of SAFe: the levels, the people, the backlogs…  The dynamic approach resonated.  I began using this same simple approach again and again.

SAFe in 8 Pictures deck

There are no bullets: only 8 pictures and 16 words. The graphical nature of “SAFe in 8 Pictures” allows you to tailor your talk to any audience. Behind it are robust speaker notes to get you started quickly. From there, you can continue building your knowledge with other content from this site.

Download SAFe in 8 Pictures 



Categories: Blogs

RabbitMQ – Best Practices For Designing Exchanges, Queues And Bindings?

Derick Bailey - new ThoughtStream - Wed, 09/02/2015 - 13:30

A question was asked on StackOverflow about best practices for RabbitMQ exchanges, queues and bindings. While this question was technically “off topic” for StackOverflow, I answered it anyways because it’s a common set of questions and offers insight in to a few points of confusion when starting out with RabbitMQ. 

Ex q bind

One Exchange, Or Many?

The core parts of the question include:

I’am looking for best practices for the design of the system regarding topics/queues etc. One option would be to create a message queue for every single event which can occur in our system, for example:


I think it is not the right approach to create hundreds of message queues, isn’t it?

Isn’t it better to just have something like “user-service-notifications” as one queue and then send all notifications to that queue? I would still like to register listeners just to a subset of all events, so how to solve that?

My second questions: If I want to listen on a queue which was not created before, I will get an exception in RabbitMQ. I know I can “declare” a queue with the AmqpAdmin, but should I do this for every queue of my hundreds in every single microservice, as it always can happen that the queue was not created so far?

It’s a difficult set of questions to answer, but also a common set. There are a lot of options and possibilities for which type of exchange is used, and how the bindings are configured for routing messages. 

One Or Many Exchanges?

I generally find it is best to have exchanges grouped by object type / exchange type combinations. In the example of user events, you could do a number of different things depending on what your system needs.

Exchange Per Event

In one scenario, it might make sense to have an exchange per event as you’ve listed. you could create the following exchanges

| exchange     | type   |
| user.deleted | fanout |
| user.created | fanout |
| user.updated | fanout |

This would fit the pub/sub pattern of broadcasting events to any listeners, with no concern for what is listening.

With this setup, any queue that you bind to any of these exchanges will receive all messages that are published to the exchange. this is great for pub/sub and some other scenarios, but it might not be what you want all the time since you won’t be able to filter messages for specific consumers without creating a new exchange, queue and binding.

Exchange Per Object Type

In another scenario, you might find that there are too many exchanges being created because there are too many events. you may also want to combine the exchange for user events and user commands. this could be done with a direct or topic exchange:

| exchange     | type   |
| user         | topic  |

With a setup like this, you can use routing keys to publish specific messages to specific queues. For example, you could publish user.event.created as a routing key and have it route with a specific queue for a specific consumer.

| exchange     | type   | routing key        | queue              |
| user         | topic  | user.event.created | user-created-queue |
| user         | topic  | user.event.updated | user-updated-queue |
| user         | topic  | user.event.deleted | user-deleted-queue |
| user         | topic  | user.cmd.create    | user-create-queue  |

With this scenario, you end up with a single exchange and routing keys are used to distribute the message to the appropriate queue. notice that i also included a “create command” routing key and queue here. this illustrates how you could combine patterns through.

Registering Messages For Specific Consumers

Later in the question set, this person asks:

I would still like to register listeners just to a subset of all events, so how to solve that?

If you need specific messages to go to specific consumers, you do this through the routing and bindings. Trying to filter once the message is in the queue, is an anti-pattern in RabbitMQ.

This leaves you with options for how you would set up the pre-filtering of messages, using routing.

By using a fanout exchange, you would create queues and bindings for the specific events you want to listen to. each consumer would create it’s own queue and binding.

By using a topic exchange, you could set up routing keys to send specific messages to the queue you want, including all events with a binding like This binding uses a wildcard to send all events to the queue for this binding. 

There are still other options and configurations, of course. Without knowing the specifics of a given scenario, it is hard to give a solid answer.

When To Declare Queues And Bindings

The last question in this set deals with when to create your queues.

If I want to listen on a queue which was not created before, I will get an exception in RabbitMQ. I know I can “declare” a queue with the AmqpAdmin, but should I do this for every queue of my hundreds in every single microservice, as it always can happen that the queue was not created so far?

There are two ways to do this:

  1. Pre-define the exchanges, queues and bindings
  2. Define them at runtime
Pre-Define Exchanges

In my experience, pre-defining exchanges queues and bindings becomes difficult. RabbitMQ and the AMQP specification allow and often require configuration to be done through the communication protocol itself.

You don’t need a third party application to configuration the layout of your RabbitMQ installation. You can use the Web Administration plugin for this if you want. But, in my experience, this leads to problems with large applications. You will run in to a scenario where the queue name and binding cannot be pre-determined.

There is some use for this, though. There will be times when you need an exchange to always be around or you want to do some quick testing to make sure things are set up correctly. The Web Admin plugin is very useful, here.

Dynamically Defined Exchanges

Because of the way AMQP works, and the need to define queues and bindings dynamically, I find it best to have each message consumer declare the queues and bindings it needs before trying to attach to it. This can be done when the application instance starts up, or you can wait until the queue is needed. Again, this depends on what your application needs.

I tend to prefer to wait until the application needs it… but there are some cases where the queue and binding should be there before the code runs, to ensure all possible messages are caught. In that scenario, having the queues pre-defined at application startup can help.

Learn Through Others’ Experiences

I know the answers I’m providing are rather vague and full of options, rather than real answers. Ultimately, there is no right or wrong answer for which exchange type and configuration to use without knowing the specifics of each system’s needs.

Truthfully, you could use any exchange type for just about any purpose. There are tradeoffs with each one, and that’s why each application will need to be examined closely to understand which one is correct.

If you’re interested in learning more about the tradeoffs and how to make decisions around these questions, I’ve written a small eBook that covers these topics. This book takes a rather unique perspective of telling stories to addresses many of these questions, though sometimes indirectly. 

Step inside the mind of another developers and learn how to make decisions about RabbitMQ Structure and Layout.

Categories: Blogs

Agile in the Real Trenches

TV Agile - Wed, 09/02/2015 - 13:22
The Agile principle of “trusting work to the self-organizing, self-managing teams” is radically different to the military doctrine of “strict top-down hierarchy, command & control”. Yet almost a 100 years ago this idea was tried out on many battlefields and the consequences are still felt today. Video producer:
Categories: Blogs

Insight from a new Scrum Master

Learn more about transforming people, process and culture with the Real Agility Program

I recently had the pleasure of doing some coaching with someone who is new to Scrum and has taking on the role of the Scrum Master as part of a team of teachers.

Edwin Portfillo - Scrum MasterEdwin Portillo  – (c) Copyright Edwin Portillo, 2015

Last week, I unexpectedly received this email from him. I wanted to share it as a thought for other new Scrum Masters in the making…..

I’m beginning to understand that being a SM involves me not coercing people into following a specific task but guiding them into  deciding as a group what must be done for the team to move efficiently.

“We never want to be in a position where 100% of the work is 80% done.

On the other hand, if 80% of the work is 100% done, you have a qualified success.”

 Edwin Portillo
High School teacher (Scrum Master – The Teaching Team)
Hope High School / Blueprint Education

As you can see, Edwin has come a long way already in his understanding of the role. Please feel free to share your Positive comments with Edwin if you wish.  I’m sure he’ll appreciate it :->

I’ll start…  Thanks Edwin for taking the time to really think about how your actions should impact your team. Thank you for sharing your ideas with new Scrum Masters in such a simple and effective way.

Mike Caspar
Passionate About Agile


Scrum –
Hope High School –
Blueprint Education –

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post Insight from a new Scrum Master appeared first on Agile Advice.

Categories: Blogs

Personal Agility Canvas

Leading Agile - Mike Cottmeyer - Tue, 09/01/2015 - 17:00


Personal Agility Canvas

personal agility canvas


A few years ago I was at an Agile conference standing around with a bunch of CSTs and CSCs and one of the CSTs said:

“The other day in class, this guy asked me if he was Agile enough… can you believe that? What a stupid question. Who would ask something like that?”

Um… me… all the time. Even though I have now been working in Agile for almost as long as I worked in waterfall, I find myself often worrying that someone is going to find me out, or that my waterfall practices are so deeply engrained that  I can’t even tell when they raise their ugly heads and start messing with Agile.

I am always concerned about being agile and getting better through practice. The Personal Agility Canvas is one attempt to help address some of my concerns. What follows is a written explanation of what it is, examples for use and how to apply it in your own meaningful way.

Click here to download the Personal Agility Canvas

Just Do It…

Where you start working on the Personal Agility Canvas does not actually matter. The ordering used below is based solely on how I normally go through each section. The main thing is just to start. I’ve personally found that it works much better when I avoid overthinking my ideas and begin filling the canvas with whatever comes to mind.

Value Proposition

This is the box I usually start with when I am filling out the canvas. What goes in here should explain how you as an individual (not your team/group/department/company) add value. How would you respond if your boss was to lean his elbow over the wall of your cubicle tomorrow, coffee mug in hand, and say:
lumberg<Lumberg voice: “on”>
“Uh, yea, so, we’re Agile now and uh… we’re not really sure why we should have you keep working here so, um, you can go ahead and get set up in the basement next to Milton.”</Lumberg>

The question is, within your Agile(ish) organization, what unique value proposition do YOU (as an individual) bring to the table? What is it about you that makes you valuable to a company that has adopted (or is working on adopting) Agile?

Given that you want to change some aspect of yourself to become more Agile
When you are this more Agile you
Then how will you be different from who you are now?

When you evolve into this new version of you, how will this Agile version of you be able to add value to the organization? Or, how will your adoption of a more Agile approach better support the organization?

This can be a tough one. Most of us have spent time thinking about the value our company, our department, or our team adds, but we rarely take the time to consider the question as if we were re-interviewing for the job we already hold. And if you get really stuck, just ask yourself WWGHD (What Would Gene Hackman Do) “I tried to imagine a fella smarter than myself. Then I tried to think, “what would he do?” ~ Joe Moore from The Heist

So, try to imagine a more Agile version of you and ask how he/she would respond to the question, what value do I actually add here?

I come from a strong project management background and I’ve spent half my career learning how to work with Agile. I spent years fighting with Agile before it really made sense to me and the work I do. That offers me a somewhat unique perspective on adopting Agile. I see the workspace through an Agile point of view, but I also have a great deal of empathy for those struggling with the transition. My own personal transition was very difficult and that has helped me learn some things that I can use to help others get their heads (and hearts) out of the waterfall and into a mindset that is more in sync with the core tenets behind Agile.


Making the transition to Agile is not easy for an organization, or a department. And it is not easy for an individual either. If you are going to go down this path, you are going to have to expect some tough challenges. The process change is not easy, but it is nothing compared to the cultural and value system overhaul that it requires. In my experience, this holds true for those who REALLY want Agile to be more like the traditional way of working AND for those who read a book, drank all the kool-aid and found what they believe is the One True Way.

Change is not easy, and you are going to need a reason to keep going when things go all Sharknado on you. It would be easy to brush this one off and say your goal is to keep your job and that your company has mandated that everyone switch, but chances are, you’ll find it much easier to stick with this during the rough spots if you can come up with a specific thing you are trying to accomplish for yourself. So, what is your personal goal? Why do you want to go through this change? What’s the win for you (personally)?

  • Do you have a specific goal for transitioning to Agile?
  • How will you define/measure success?
  • What indicators will let you know your goals have been achieved?

You may want to work in a more creative environment, or with a closely knit team that you can collaborate with. You may want to be part of a team that can deliver consistently. My favorite answer to this question came from someone who attended a workshop I ran on using the Personal Agility Canvas. He was an old school PM who was working with a team that had started using Scrum. He was struggling not just with a new way of working but with the fact that there was a whole new vocabulary he didn’t understand. His response “I just want to feel less stupid when I talk to the Agile people.”


One thing about setting goals, they need to be attainable. This is not the list of stuff you’d ask the Genie for after you freed him/her from the bottle. Your goals need to be few in number and they need to be realistically achievable in a relatively short time-frame. If there are too many, they are too grandiose or they are open ended, you may become discouraged and they will start working against you. A big part of this is not just achieving the goals, but developing the momentum you’ll need to keep working on transforming yourself.


Each of us has things about us that will propel us forward with the change that Agile brings. It is important to identify the strengths that you have because it is easy to get discouraged about making the switch. If you can identify a few things about yourself, how you work, how you think, etc., you can find a way to leverage these strengths to help you succeed with the goals you are setting for yourself.

  • What about you, your mindset, and/or your level of discipline will help you during your journey to a more Agile you?
  • What abilities, behaviors, personality traits, or habits will you be able to leverage to strengthen your successful transition?
  • What experiences and/or training have you had that will serve you during your transition to a more Agile way of working?

Maybe you are someone who has experienced the strength of a good team first hand. Or you are someone who is just naturally open to experimenting with trying new things to see if they work better for you. I have a lot of experience in working with both Agile and traditional approaches of work. This experience has allowed me to see value in both ways of working and has led me to a point where I am less focused on process than I am on results (cough…outcomes).

I consider this to be a strength for two reasons. The first is that while I see value in learning new processes/approaches to work, I tend to not get so hung up on the idea of doing it “right”. It has also left me with a healthy skepticism. I take an empirical approach to how the different tools/methods/processes work. I do tend to start out trying to be disciplined about using a new approach, but trial and error wins the day in the end.

Interactions with Others

How we interact with others is a big part of the cultural change that comes with moving to Agile. This can relate to how we communicate with people, our ability to trust, our openness to differences of opinion and our ability to be empathetic to others who may be further along, or not, than we are with making this change.

If you come from a traditional background, believing that you can trust others to make good choices in the work they do and in solving problems for the customer can prove to be difficult. A lot of this may just be about being mindful of how we talk to people and how we react to the possibility of failure. No one likes to fail, but it is important to remember that each failure creates an opportunity to inspect and adapt and succeed next time.

Consider the way you interact with others, how you lead and are led, how you communicate and how you think and feel about the people you work with.

  • Are you practicing transparency?
  • Are you willing and able to trust others on your team?
  • Is this demonstrated through how you interact with people?
  • Do you need to control things others do to ensure they are done right?

In the 1960’s, Douglas McGregor was working at MIT’s Sloan School of Management and he came up with “Theory X and Theory Y”. Basically, Theory Y assumes that if we give people what they need and the freedom to make a choice, they will work hard and do good things. Theory X, (not so much with the Agile), believes that if we do not offer the carrot and the stick (or often, just the stick), that people are inherently self-serving and lazy. Agile is much more in the Theory Y camp. One thing I had to recognize when filling this out was that while I REALLY want to be Theory Y, I have had a lot of work experience that pull me more into the Theory X camp. The way this plays out in my interactions is that if I am not careful I can easily slip into the “just do this because” mindset.


This is probably the easiest of all the boxes to complete. Consider your working environment, the tools you have at your disposal. In working towards a more Agile approach, do you have everything you need to succeed?

  • Are there things about your working environment that aid or impede your ability to be more Agile
  • What could (should) be changed to better support your transition to Agile?
  • Are there things in play that could be amplified to enhance your personal adoption of Agile?

If your team is not collocated but are in the same building, maybe you want a space where you can all work together. If your team is distributed, maybe you need video conferencing for Daily Standups or a few big monitors to hang up so everyone can always see the task board. Or maybe you just need a rolling white board you can all share.

I use Personal Kanban to manage my work. When I am home and have my whiteboard, it works great. But, I travel a lot and I can’t bring the whiteboard on the plane. Yes, there are plenty of electronic tools out there, but most of them require internet access and they are no good to me at 30,000 feet. While solving this is still a work in progress for me, it is something that I know I need.

Also, because I love what I do, I have a tendency to want to say “HELL YES!” to every opportunity that comes my way. Work is important to me, but my family is much more important. I have learned the hard way that I need help with remembering to protect the time I have to be at home and fully present with my wife and daughter.

The Mark Inside

In the book “The Ticket That Exploded” William Burroughs said “ Husters of the world, there is one mark you cannot beat: The Mark Inside”. Burroughs was referring to the fact that each of us, like it or not, is our own impediment. No matter how hard we try, we can never truly see ourselves outside of the narrative we create for ourselves about our own life. This is true in work, and it is true of our adoption of Agile. While it may not be something any of us can fully overcome, it is something we must be mindful of, always seeking understanding. Part of the relentless pursuit of continuous improvement that is inherent in Agile, is always trying to see the ways in which we are keeping ourselves from getting better. (Having an accountability partner can help a lot here see the end of this post.) In what ways are YOU the impediment to achieving your goals for a personal adoption of Agile?

  • How trusting or skeptical are you in the “promise” of Agile?
  • How disciplined are you in your practice of Agile?
  • Are you hedging your bets because of “how things work in the real world”?

The trick with this is to try to develop awareness without judgment. For many, this is much harder than it sounds. If you have established goals for adopting Agile and you aren’t meeting them, are you able to see why? Maybe the goals were not realistic, maybe there are other factors that are contributing to your situation and you need to take those into account and reset. What you are working for here is a better understanding of how you are approaching the changes you are trying to make and learning more about yourself along the way.

I believe that once you learn traditional project management, it changes the way you look at the world. I am a project manager and I spent a lot of time refining my ability to see things that way. But, now I work in Agile. While I cannot un-learn traditional project management, I know that I need to pause for a few seconds to let the Agile filters kick in before I speak. The healthy skepticism that I listed earlier as a strength is also something that factors in here. I need personally validated proof in order to truly believe that changing how I work is going to help. While this is a strength, it also leads me to being a bit reluctant to just jumping on board with new ideas.

Desired Changes

What are some possible areas of focus where you may want to introduce a change that will improve your ability to adopt Agile on a personal level?

  • Behavior towards others
  • Speech
  • Mindset
  • Openness and Transparency
  • Knowledge and experience gaps
  • Willingness to Trust

Because of my experience working as a traditional PM, there are still language issues to be aware of – like referring to the humans who do the work as “resources”. I also have some gaps in the things I know about Agile that I continue to work on. And I know, that despite my best efforts, I still struggle with trusting that left to their own devices, and provided with the things they need, that people will do good things. I’ve gotten much better at this, but I still periodically run across situations that drag me back into the Theory X camp.

I have found that in working on this section of the canvas there are two things to consider. The first is to try avoid going from desired changes to negative self-judgment. The second is to keep this list reasonable. It is easy to come up with a bunch of stuff we all need to work on, but trying to maintain a list of things you can actually achieve in a relatively short time frame can be challenging. Be clear and keep it simple.


Transitioning to Agile is not an easy thing. There may be a lot you have to let go of and many of those things could be exactly what got you to where you are today. Change is scary and it is normal to be more worried about the devil you don’t know. So what about the possibility of Agile as a cause for anxiety or stress?

  • Does the possibility of letting go of the things you have learned to do in work give you some angst?
  • Do you worry that adopting Agile might have a negative impact when you start explaining to management you they aren’t getting a Gantt chart and that despite your PM Certification , you can’t actually be trusted to accurately predict the future?
  • Are you seeing roadblocks or are you so deeply under the sway of responding to every impossible request by saying “YES” that you are stuck in the “Yeah, well, Agile sounds cool, but that will never work at OUR company because WE’RE special. “

When I first started working with people who were Agile, I was always scared that I was going to be caught or found out and exposed as a traditional PM.  I dealt with this by trying to overcompensate for my traditional background. This completely worked against me.

Actions Needed and Accountability Partnerships

Step 1: Take few minutes to review your Personal Agility Canvas. Come up with a list of 3 to 5 actions you believe you could accomplish in a relatively short time frame. These should be things you can measure and feel comfortable committing to and they should be focused on helping you reach whatever you are aiming for in terms of becoming a more Agile version of you.

Step 2: Write each action out, set a realistic deadline for each of the items and figure out how you will measure success, or define done for each of these items.

Step 3: Check your action plan against the goals you’ve set. Will the actions help you get there? If not, why and do you need to change one or the other.

Step 4: Go find an Accountability Partner. My suggestion is that the partner you find should be someone you trust to give you honest feedback and will be willing to call you out on things or challenge you when things seem off.

Step 5: Share your list of actions with your Accountability Partner. You don’t have to share anything on the canvas but the Action box. The rest may be fairly personal. When you share the actions, make sure to let your partner know about the deadlines you’ve set and how you will measure performance towards those goals. The job of the Accountability Partner is to check in with you if they have not heard back by the time the established deadlines hit. If you don’t hit them, that is between you and your partner, but they should be willing to challenge you on why if the goals are not met.

Establishing an Accountability Partner serves two purposes. The first is that your partner should be willing and able to serve as a sort of Personal Agility Trainer for you (like you’ve had in a gym). The second reason is a but dysfunctional but I have found that the guilt that comes from knowing someone will be checking up on me is a strong motivator.

Once you and your partner reach a shared understanding about their role, your goals and how you plan to achieve them, then it is time to get to work. You should expect that sometimes you’ll succeed with these things, sometimes, not so much. The trick is to continually inspect and adapt along the way. Should you decide to use the canvas, it would be great if you returned to this post and shared your experiences with the canvas.

Click here to download the Personal Agility Canvas

The post Personal Agility Canvas appeared first on LeadingAgile.

Categories: Blogs

NeuroAgile Quick Links #13

Notes from a Tool User - Mark Levison - Tue, 09/01/2015 - 10:02
A collection of links to interesting research from the world of neuroscience and behavioural psychology that can be applied (or not) to Agile/Scrum Teams. NeuroAgile Quick Links from Certified Scrum Trainer Mark Levison


Categories: Blogs

Delivering Training in an Agile Way

Ben Linders - Tue, 09/01/2015 - 08:17
When a client asks for a training session, most often the full content of the training is discussed and defined up front. With one client that wanted a week of training I took a different approach. The client an I used a backlog to prioritize training sessions and workshops. We only planned the first days, and reflected and adjusted the training every day of the week. This is a story of how I collaborated with a client in an agile way to ensure that they would get the biggest possible benefit out of a training week that I delivered to them. Continue reading →
Categories: Blogs

Phone Screening Junior Candidates

Phone screening junior candidates is hard. With 20+ years of experience I find it hard to evaluate someone who’s new to the field or worked less than 6 months. What I’m looking for is potential, but I can’t fall back on traditional measures where I ask for evidence of a skill. Sure they might have a beginning grasp of some language or the ability to put together a bare bones web site or iPhone app, but I really can’t drill them on OO, Domain Driven Design, or functional programming.

My approach has been to touch on some real basics to determine they’ve at least been exposed to subjects they claim on a recipe. Then I dig for stories of how they picked things up, what they learned from mistakes

Step one, is read the resume. They tend to actually be one page! Note anything I should ask them about such as basic language syntax or their explanation of TDD. Second, is take a look at any open source code you can find, often github. Ignore that it’s sloppy or untested and just take a good look at it. Then if you have time you can do some Googling and see what kind of data you can find about their participation in the community or even just questions on forums or Stack Overflow.

Next comes the actual phone screen itself. I have a stable of questions I use, a few I always use and many that I sample based on the interviewee’s experience:

  • What have you done in 2 minutes or less? (I’ll let this go over 2 minutes if I’m getting good information, but sometimes you just have to tell people you need to move onto the next question.)
  • I usually warm up with a question about the disadvantages of inheritance. This often throws junior candidates, but you can get a pretty good sense of how much OO they really understand this early in a career.
  • As I’m a die-hard TDD/BDD type I always ask them to describe how they’d write a test in their current unit test framework. A surprising number of resumes that claim to practice TDD can’t explain the syntax behind writing a rspec or Junit test.
  • I’ll often ask a question about a situation where they didn’t have enough information to complete an assignment and how they handled that. Sometimes this sort of behavioral question throws junior developers and I have to reiterate that I’m not looking for a theoretical answer.
  • Then I’ll jump around from behavioral questions to technical questions. I might ask about what an index is or what they find most challenging about their current project.
  • Almost always I include a question on how they come up to speed on new technologies. I’m looking here for anything they learned that wasn’t just presented to them in a class or at their job.
  • Finally I wrap up with a few standard questions:

  • Why do you want to work for us?
  • Is there anything else I should ask you?
  • What questions do you have for me?

Every few months I come through the questions and usually add a few and remove the ones I never ask. I still wish I had a better process, but the most common theme to come out of junior phone screens is that they’re enthusiastic and they know at least what they claim on the resume.

Categories: Blogs

Holding a Tech Lead course in Sydney - Mon, 08/31/2015 - 18:27

With a one-time only opportunity this year, I am running a course for Architects and Tech Leads on 22-23 October at the ThoughtWorks Sydney offices. After interviewing over 35 Tech Leads for the Talking with Tech Leads book, I recognised there is a gap about teaching developers the special leadership skills a successful Architect and Tech Lead demands. The class size is really limited, so reserve yourself a place while you can.

Tech Lead

In this very hands-on and discussion-based course, participants will cover a wide breadth of topics including understanding what a Tech Lead is responsible for, the technical aspects a developers rarely experiences and is not accountable for, and the difficult people-oriented side to the role including influencing, relationship building and tools for better understanding your team.

This is a two-day course that will quickly pay back dividends in accelerating you on your path or further developing your Tech Lead skills as developers. Register here on eventbrite for the course 22-23 October.

Categories: Blogs

“The story I’m making up…”

Thought Nursery - Jeffrey Fredrick - Mon, 08/31/2015 - 17:13

Last week at the August session of the London Action Science Meetup we started with a discussion of the phrase “the story I’m making up…” I love this phrase! It captures the process of the Ladder of Inference, but it has an immediate emotional resonance that the ladder does not.

I came across this phrase from an unlikely source: Now I’ve got nothing against Oprah, but this it just isn’t in a url that shows up a lot in my browser history! So the real credit goes to @frauparker, who is someone I clearly trust well enough to follow off into the well-scrubbed bright and shiny parts of the internet; in this case an article by Brené Brown on How to Reckon with Emotion and Change Your Narrative, an excerpt from her new book Rising Strong. The article is well worth reading but I’m going to take a look at it through the narrow lens of the action science workshops I’ve been leading.

For a few months now I’ve been leading weekly lunchtime workshops at TIM Group where anyone who is interested can join in a discussion of some two-column case study. This might be a canned case study, or one people recall and write down on the spot, but the best sessions have been when someone has come with something in mind, some conversation in the past or future that is bothering them. As a group then we try to help that person to explore how they were feeling, what they didn’t share and why, and how they might be more effective in the future. One of the common observations, and one this article reminded me of, is how hesitant the participants are to put their feelings into words. It seems we can almost always have a productive conversation by asking the series “How did you feel at that point?” followed by “Is there any reason you didn’t share that reaction?” These questions get quickly to the real source of our frustrations that are hiding back in the shadows. Bringing them into the light we find out something quite surprising: they were stories we were making up.

The article has good advice that will be familiar to students of action science and the mutual learning model, suggestions like separating facts from assumptions, and asking “what part did I play?” It also had a key action that is hidden in plain sight. Do you see it in this exchange from the article?

Steve opened the refrigerator and sighed. “We have no groceries. Not even lunch meat.” I shot back, “I’m doing the best I can. You can shop, too!” “I know,” he said in a measured voice. “I do it every week. What’s going on?”

As I read the remainder of the article from the author’s point of view it was easy to overlook the role Steve played here. It was his calm empathetic question that allowed the author to reply with the title phrase: “The story I’m making up is that you were blaming me for not having groceries, that I was screwing up.” I really struggle generating this kind of response, of not getting caught up with my own emotional reaction. So I admire what Steve accomplished here.

I’ve long said that “stories are the unit of idea transmission”. What I hadn’t realised before reading this article was how powerful I’d find using the word story to describe what is going on in my head. I’m really looking forward to practicing with this phrase in future conversations.

Categories: Blogs

Agile 2015 Video Interview

Agilitrix - Michael Sahota - Mon, 08/31/2015 - 16:09

Olaf Lewitz and I were interviewed at Agile 2015 on coaching and helping organizations become more adaptable (anti-fragile) through safety – leadership – trust. I am really happy how well it turned out.  

The post Agile 2015 Video Interview appeared first on - Michael Sahota.

Categories: Blogs