Retrospective 65 – NOT Scrum and Insane Agile Teams


Agile New Year – 2011 – A Year In Pictures

There are tons of things to be thankful for this year. It’s been a crazy one.

I spend a lot of time in photoshop. Mostly just to have fun and create something funny for the blog post that I’m writing.

This year I’ve decided to highlight some of my favorite posts, based on the photoshop picture. These, unfortunately, are not some of the most popular posts of 2011, but that don’t matter. 🙂

Enjoy, and I look forward to growing with the Agile community in 2012!

Favorite Blog Posts in 2011 Based on Pictures


Continue reading “Agile New Year – 2011 – A Year In Pictures”

[Giveaway Winner] – How to Create a Successful Blog Business

Winner alert:

How to Build a Successful Blog Business

WINNER: Beatriz – Shoot us an email at [info AT agilescout DOT com] with address and we’ll ship it out!

See Our Past Giveaways:

Help us give away more awesome free stuff to our community and readers! [Become a Sponsor]

Teams Over Processes – Don’t Be Insane

[Guest Post: Craig Strong, MBCS CSM has been involved with software production for over 12 years and is currently contracting as a ScrumMaster for Sky. Having been a developer Craig has experienced first hand the effects and problems when being managed by various project management techniques and frameworks. On a daily basis Craig is responsible for managing,coaching and improving cross functional teams using Agile. Follow him on Twitter @craigstrong and blogs at]

Do we really need to do that?

One of the embedded issues which often exists in most cultures is the accumulation of processes. Processes make people comfortable and empowered. People are generally creatures of habit and enjoy routine. If people feel good about such things its tempting and common to see more processes emerging to strengthen or improving the existing processes. Now don’t get me wrong, certain processes and frameworks are essential and have high value to business. However sometimes where they exist, they are the main focus and not what the process was setup in the first place to achieve.

When you get a group of people together and put them on the same project they are not a team they are simply a group of individuals. By applying processes, frameworks or tools to this group it’s likely they will simply be a group of individuals using processes, frameworks and tools. Not only will this not help build a team, but could slow down the group of individuals.You don’t build teams by simply applying a framework or process. Certain processes are inherited from previous projects so they must be applied again. In some cases they didn’t even work well previously, but were in place and therefore must be re-used. There is no such thing as silver bullets which when applied guarantee success.

As the famous quote says :

Insanity: doing the same thing over and over again and expecting different results. – Albert Einstein

agile team product managementA colleague of mine recently made a profound simple statement, which was “question the value of everything, if you don’t know why or can’t remember why you are doing something, just stop doing it.”

As simple as this sounds, it’s very true. How many of us are routinely writing and/or requesting documentation, forms or following certain processes because we are used to it not because it’s really needed. If you question some of these and ask yourself why you are doing something or why do you need this information and how is it going to be used, you may find that you don’t really need to continue with it. When you stop doing such an activity from then on, you will have free time to do something of value. Not only in such cases can you improve value, but you might just stop doing something which is devaluing the situation.

In Kanban this is often seen when you are visualising workflow. By visualising the workflow you can identify routes of inefficiency and routes to improvement. The same can be discovered when undertaking Lean analysis. This regularly proves to provide fantastic results over time. However sometimes outside the direct workflow of production it’s worth questioning other not so tangible artefacts. In doing so you may eliminate waste and identify micro-management which can and needs to be challenged. A process is not beneficial unless it has a clear value which should be easily identifiable. Value isn’t something which is nice to have, but something which clearly delivers or benefits a person, group, company or product.

So next time you are about to spend 30 or more minutes writing a report or asking someone else to provide you with a graph, ask yourself “Do we really need to do that?”

Agile in Lean Manufacturing and Value Stream Mapping – I’m Here

Living it Up In the Back of A Gigantic Plant

Welcome to my view. Seriously. I could not be more excited to work for this client. I’m getting to help lead a small development team better understand and deliver a new automation system for a manufacturing/shipping plant.

What excites me the most is that, as an engineer, this really gets my blood moving. I’m literally uber excited to be part of a manufacturing automation system at work. Rock on. I’m also excited about blogging about this experience. Not many Agile Coaches get to work outside of strict technology and software product development.

One of the first things I did was spend the day understanding our value stream. After interviews, process diagrams, and conversations with the team, I built out this nice old omnigraffle of a high level view of the value chain, from receiving to moving through the system. You’ll notice that we have 2 releases of our new automation system (small font).

We need to eliminate waste AND build a system that accounts for increases in cycle time. YES! Let the challenge begin.

“Walk within yellow lines…”

Now, if I can only find my yellow hardhat.

Here is a quick and dirty video on value stream mapping and the value. 5 minutes. You’re not working anyways. It’s after Christmas. 🙂

NOT Doing Scrum – Back to the Basics

[Guest Post: Don Gray is an Agile Coach whom I have had the pleasure of working with on one of my biggest clients. There is too much to say about him. He kicks ass. You can find him blogging on his website and follow him on twitter @donaldegray] – He also purposely tries to confuse me and challenge me at any given moment.

I recently talked with a company who wanted to use Scrum for their production support team. The team had 670 defects ordered in business priority and needed to work from the top down. Corrected defects would be deployed to production once a month, except quarterly when then deployment would synchronize with new development’s deployment. No planning meetings needed and no demo prior to deployment.

About a week ago the following question was asked on the scrumdevelopment listserve:

“Sometimes, I feel ScrumMaster role is redundant. Is it possible to have Scrum without ScrumMaster?”

Once from the top with feeling

I did not define Scrum. Those who did (Ken Schwaber and Jeff Sutherlund) created a simple process framework and minimal interacting roles.

The process has these ceremonies, or meetings if you prefer:

  • Sprint planning – happens at the beginning a sprint. Sprint means a time period (usually between 2 – 4 weeks and shorter is better in my experience) where the team produces the value they agreed they would. Sprint planning often divides into two meetings: first the team estimates the amount of work they can accomplish, then they task the work and have a sanity check.
  • Daily standup – occurs every day at the same time. The team members share their progress since the last standup and report any blocking issues.
  • Sprint demo – where the team demonstrates to the product owner the value they completed in the sprint. The product owner has final say on accepting the work products, or not.
  • A retrospective where the team inspects the previous sprint and selects an improvement goal for the next sprint.

Interacting roles:

If it looks like a duck …

If you’re not following this process, and don’t have these roles in place, please don’t say “We’re doing Scrum.” You’re not. You may be following the agile principles,, and that’s great. But you’re not doing Scrum.

Retrospective 64 – The Process of Change 4 Part Series


C-Jump – Christmas Gift for Your Little Programmer


Need a great gift for your kid? Boom. Teach them real-world valuable skills: TO CODE.

Is while ( x > 0 ) an endless loop?

See how to play the game here.

c-jump facts:

  • This game is not only about teaching and learning: it’s fun and entertainment for the whole family!
  • Skiing and snowboarding is a perfect programming analogy.
  • c-jump game is ideal for home school education.
  • The game is based on the code of a real computer program!

Want to grab a copy?  $25 bones.

The Process of Change – Complexities of Attitudinal Change – Axiology [Part 4/4]

[Part of the 4 part series on The Process of Change. See the others]:

The Complexities of Attitudinal Change

Everyone behaves in a way that makes sense to them. Everyone rationalizes his or her behavior.

Axiology – the understanding of values. If a person does not value a change they are not going to go along with it. The opposite is true as well. If he or she feels that you are attacking something he or she values, they are going to react negatively.

Ok, so that sounds tough. You’re right. It is tough. The human side of software development is understanding people. People are driven differently, people are incentivized differently.

Facilitating attitudinal change:

1. Understand that we change people through interpersonal communication:

  • Not by arguing at or with them
  • Not by talking them down
  • Not by telling them or implying that they are less intelligent then others
  • Not by talking talking talking. Listen listen listen
  • Not by assuming. Ask questions

People tend to change, or be more open to change, when they can exchange ideas with other people.

2. Understand that people change by basis of information:

  • Help people to understand the necessity – Let’s have a conversation around why this is necessary… or is it?
  • Help people understand the value or benefits – Let’s have a conversation around the value… or eventual value of the change.
  • Help people understand the feasibility of the change(s) – Let’s have a conversation around how the change is possible. Yes, we can do it.

Wrap up:

Creating change in your organization is tough. Period. It will take patience, facilitation, and maybe even a bit of pressure in the right places… and on the right people. Change implementation takes strategy, hard work, and thoughtful consideration of your system (environment+people). Handling resistance to change is tough, tap into your humanity. You’ll need it, and good luck.

The Process of Change – Handling Resistance to Change [Part 3/4]

[Part of the 4 part series on The Process of Change. See the others]:

Handling Resistance to Change

People fight change because change makes, in a lot of ways, “current value” questionable. What we were doing yesterday… and continuing to do, might not be exactly right. In a lot of ways, change can be a sort of slap to the face. An invalidation of what has been ‘working’ before.

It appears, to some people, that in the process of change things are coming apart. Conflict of interest arises when people face meaningful alternatives and then they fight the change. They fear the possible disorganization that comes as a result of the change. They simply don’t want to leave the status quo because it is comfortable.

“Music has charms to soothe the savage beast.” – William Congreve

This is where the master facilitator must soothe the insecurities and fears that people have when it comes to change. Your ability to hold the line, quell peoples fears, and normalize the experience is crucial here.

We know that change is unavoidable and tends to affect the goals and direction of a company or teams in positive ways. We just have to be ready for the resistance that will come.

So, what should do we do when facing resistance?

I thought for a good while on this particular segment of this post. I came up with 4 bullet points, but in sum total, they all fell into basically one idea:

Find the Truth

Recognize why people resist change – don’t make assumptions. Find the truth. Is it the change or the method of change? Is it personal for some people? What types of baggage do people have? What nuances and idiosyncrasies are at play? How does the whole ‘system’ (people+environment) work?

I wrote about this before in my post People Not Technology as well as my post on KNOWING your Team. What we’re talking about here isn’t all the mushy-gushy stuff, but really understanding all the pieces of the system that are at play. Your investigative skills will play a huge role here. It’s hard work, but digging, asking the right questions, having the right conversations, and being available to criticism, feedback, and even arrows in your back, are all part of the job.

The Process of Change – 3 Levels of Change-Implementation [Part 2/4]

[Part of the 4 part series on The Process of Change. See the others]:

The Three Level Process of Change-Implementation

1. Planning of Change – what we want to change and why (remember metrics, as well as the reasons why we’re doing Agile). The desire of the leadership is to bring about change as effectively as possible. A measure of effective change is that things remain stable. While there is some value in ‘breaking things up’ and creating some dissonance for positive change to take affect, we need to be careful, as coaches, to balance the approach.

  • The leader or change agent must have comparative ways to think about change (conceptualization, review of models or examples). Story mapping works well here, visualizing the whole (lean concept), and transparency (wallboards/other visual aids).
  • The leader must consider the decision-making approaches allowed within the team/organization/company, ie., how are decisions made and approved?
  • Determine how much freedom of decision-making capacity you have without the input of others.

2. Developmental Level – plans are solidified and a strategy is put into place as to how we are going to execute the change. Incremental change is good here. Start small, start effective. Prioritizing change is important. There is a lot of work to be done, and we can get to all of it in due time.

  • Stakeholders or vested parties in the change must be on board, accountable, and ready to execute the change.
  • Internal champions are a big plus here.
  • Determine the roll out strategy: Are we starting at the team level? Enterprise level? Architecture first? Technical debt first? Training? Etc.

3. Announcement Level – the revelation of the change to the company and teams. The change has been decided in due process through the planning of the change as well as the development of the change. It’s time to announce it.

  • Should this be you? Probably not. Internal stakeholders should really take the reigns of announcing the change.
  • Metrics! – Why are we doing this? Tell me why we’re doing this change, tell me how it’ll make things better.
  • Make it fun – Hopefully (if you can) there can be some excitement around the change. Hey, we’re making things better!
  • Make it visible – Email sucks. Meetings suck… but don’t have to be. Be creative as to how you announce these changes. Informal can work too.

The Process of Change – The Agile Change Agent [Part 1/4]

[Part of the 4 part series on The Process of Change. See the others]:

[Part 1] – The Agile Change Agent – Understanding Change

As an Agile Coach, I have realized over time that cultural change is something not fully understood nor embraced enough during the process of bringing Agile into a company. Whether it is an Agile adoption, or moving towards transformation, we must take a deeper look into what change is for software development teams, departments, and enterprises alike.

I’ve decided to tackle this in a four part series, taken from my experience. Feel free to comment and let me know if I’ve missed anything 🙂

Change is not an option, therefore …

We must recognize our role as “change agent.” We do not just keep the software development running smoothly and manage the day to day activities. We are more than that. We’re Agile coaches! We must recognize that change happens and we must be prepared to handle it or deal with or strategize with it. This means we must have certain skills.

  • We must identify the needed coaching that is essential for the teams and enterprises. What is the primary value-add? Why are we doing Agile? What problems are we trying to solve?
  • We must help the people within the enterprise understand and follow the coaching recommendations and why it is valuable to improve and change. Coaching is so much about shepherding teams and companies through the process. Change is hard. Sometimes it hurts.
  • We must show the benefits of the changes. ROI anyone? Metrics? What is the value proposition at the end of the day?
  • We must strengthen their motivation to move in a certain “new” direction. This can take time. This is the long-term role of an Agile Coach. Embedded coaching works, but it’s not going to be a 1-month turn around. Get deep. It’s going to be a long winter.

6 Guidelines for Understanding and bringing about Change:

Continue reading “The Process of Change – The Agile Change Agent [Part 1/4]”

Behind LeanKitKanban – Jon Terry

I’ve been working connected to Jon Terry [Twitter: @leankitjon] for a good while now, and have really enjoyed what he brings to the Agile/Kanban community. I recently met up with him at AgileDC in which I was thoroughly impressed with not only who he is, but how he promotes and supports others. Truly a standup guy.

I caught up with him and asked him a few questions around himself, more on startups, and just a small bit on the really cool kanban tool that his team has built. The interview is very enlightening, and I would highly suggest grabbing some of the golden nuggets of wisdom that Jon has to share.

Tell us about yourself, background, etc.

My dad was in the Army so we moved around a lot, mostly in the US but also Germany. I went into the Army myself for a little while after high school. When I was done and went to college, my degrees were decidedly non-technical or business – the history of US foreign policy and print journalism. I think I had aspirations to be the next Tom Friedman.

I worked in journalism for several years, both in college and after. I started working when newspapers were first experimenting with this new-fangled Internet thingy. None of the more experienced editors wanted to be involved, especially because working on the Web edition meant you were on the late, late shift until 4 in the morning. But I thought it was pretty interesting and I could already see that electronic distribution was eventually going to hurt print publications.

I remember telling a group at a student journalism conference that they ought to look for other work because the Internet was going to ruin their careers. Sadly I was right.

In the meantime, though, I had moved on to a sales/marketing job at an Internet start-up called We built websites for hospitals. We weren’t “really” a start-up because we were funded by the giant hospital company HCA, but there was still a lot of that start-up energy and enthusiasm. It was a lot of fun for about a year and then the bubble burst – at which point having a corporate backer turned out to be very useful.  I ended up spending about eleven years with HCA as a business analyst and project manager in their supply chain line of business – where I met my LeanKit partners Chris Hefley, Stephen Franklin, Daniel Norton, Kelly Baker, and JR Allen.

In my final role at HCA as director of project management, I helped start the Lean/Agile transformation of HCA’s IT organization. It’s a huge group, 4,000+ people across the US and India, so the change is still in process. But it’s been very successful – truly getting into Agile at scale. I first met Sanjiv Augustine from Lithespeed and Mary Poppendieck during this time. I was more of a “pure” Scrum guy back then, but both of them got me thinking more broadly about Agile and Lean.

What got you into the startup scene?

Honestly, I was pulled into it by my partners. Most of them left HCA before I did, but we met regularly for lunch and kept saying we ought to start a company.  I wasn’t quite ready to leave HCA. I was also getting my MBA at the time so I was pretty busy. But Chris, Stephen and Dan went ahead and founded LeanKit in 2009 and almost immediately made me a board member. They helped me see that, even though I had a great job at HCA, making the move to a start-up was going to help me grow as a person. My work with the company gradually increased until I started full-time earlier this year.

Making the jump into startups, what would you suggest for new startup folk before they take the plunge?

First, understand the job.

Continue reading “Behind LeanKitKanban – Jon Terry”

Agile Army – Reducing Accidents and Saving Lives

The Army released a new web-based tool called “Army ReportIt!” that is designed to be more accurate, timely and complete by combining several existing Army accident reporting systems.

“This tool will give our leaders, at all levels, a better picture of the Army accident landscape,” said Brig. Gen. William T. Wolf, director of Army safety and commander of the U.S. Army Combat Readiness / Safety Center, Fort Rucker, Ala. “It empowers them to better understand the types and circumstances surrounding accidents so that they can develop preventative measures.”

Army ReportIt! developers strived to ensure that it would not only be quicker and easier to use than those systems it replaced, but provide quicker user feed-back.

“ReportIt is easier to use than the systems it replaced,” said Melissa Johnson, director, G6, support operations, USACR/Safety Center, “because we designed a very user-centric, familiar, web-based interface. We are developing ReportIt on the .NET platform using Agile methodology to enable us to respond quickly to user feedback. And, of course, we are vigilant to maintain Army information assurance standards as well as Privacy Act requirements.”

Sounds good to me. Now… if only they could think of cooler names for these types of systems…


Wikipedia is Agile – One of the Worlds Largest Websites Manages Data with Agile

Fundraising is hard. Period. Managing one of the largest websites in the world…well, you gotta use Agile. In order for Wikipedia to manage not only the large amount of data but also continue to fund their project they had to approach their workload in a very agile and iterative fashion.

[We’ve written about updates to Wikimedia’s Agile approach before]:

The fundraiser brings all sorts of uncertainties and in order to respond to these uncertainties, we had to approach it in a very agile and iterative fashion. Through daily SCRUM’s and keeping our clients close, we worked together to respond to changing requirements while maintaining a sane work load. We kept an up to date list of our backlog on meta and used this on a daily basis to organize our work, prioritize incoming requests, and keep our clients informed. We did timely code review, qa, and deployment while balancing responsiveness of project delivery.

One of the toughest challenges that Wikimedia Foundation found was to balance ease of changes for quick testing while maintaining strict security requirements to safeguard their donors’ privacy. They also developed new methods for quick content creation, reliability and deliverability.

In order to assess their progress, they made use of a check-in mid-fundraiser and another at the end of the fundraiser (sounds like a retrospective/demo). This allowed us to connect directly with members of the fundraising team to asses our progress and course correct as necessary.

[HT: Wikimedia]

Retrospective 62 – Books and Giveaways


[Tool] – Riviera – Record with Skype!

A miscellaneous tool for this Friday, but I think a really useful one.*WINDOWS ONLY* Sorry all you Mac users…

If you do a lot of calling, or teleconferencing, or interviewing using Skype, then this can totally help you when you need to record and take notes.

[Enter]: Riviera for Skype

Why You May Need a Skype Recorder:

  • Help your business
  • Protect your reputation
  • Record interviews, tech talks, conferences, audio casts, pod casts for learning later, etc.


  • Automatic and manual Skype call recording
  • Records Skype calls of any type: Skype-to-Skype calls, SkypeIn / SkypeOut, Conference calls, calls to cells, etc.
  • Records Skype calls of any length
  • Recordings are stored in separate MP3 file
  • No functional limitations in free trial version. Only 14-day trial period
  • Skype Video Recording (soon)
  • Built-in MP3 player for playing recordings
  • Very easy to use – starts working immediately after launching, no configuration required
  • Free support and advice
  • Free lifetime updates and upgrades
  • Ideal for recording interviews, conferences, podcasts
  • System requirements: Windows XP/2000/2003/Vista/Windows 7

[Giveaway] – How to Build a Successful Blog Business

We’re moving into December, and for all you bloggers out there, who may want to improve their strategy as a blogger… this may just be the book for you.

How to Build a Successful Blog Business

“How to Build a Successful Blog Business is a straight forward guide to building a publishing business online that covers everything from choosing a niche to hiring staff, registering a business to selling it, finding traffic to monetizing it. Whether you are interested in creating an additional income stream or building a fully-fledged business, this is an essential read for web entrepreneurs and online publishers. Collis is a web veteran with a wealth of experience and an easy to read style. He has founded sites such as the Tuts+ network, the Envato Marketplaces, FreelanceSwitch and AppStorm which combined serve up over 50 million pageviews a month.”

If you want even more information on how to become an awesome blogger that makes cash, check out

How to Enter:

  1. Comment on this post
  2. Tweet this post

Simple. Jump on it! Contest entry closes (for this month) on Dec 16th, 11:59PM.

Boom goes the dynamite.

See Our Past Giveaways:

Help us give away more awesome free stuff to our community and readers! [Become a Sponsor]

Book: DRiVE – Daniel H. Pink Quotes

There are some books that just glue you to the seat. The best books, you keep just an arm’s length away so you can read, re-read, and continually think about and marinate on. DRiVE, by Dan Pink is one of those books.

I’ve read this book a total of 4 times now, and this past time I really wanted to make sure I not only highlighted parts I missed before, but to take notes on them. I thought I’d share some of my favorite quotes from the book (and hope it’s not some copy write issues…) Please! I meant no harm, this book just kicks booty!

How this book applies to my work as an Agile Coach is that it helps me better consider how teams, companies, organizations, and systems all work together. It is, after all, people who build software, not technology. The better we understand, empathize, and motivate people correctly, the better products and services will be.

I would highly suggest any organizational change agent, consultant, or coach to read this book. It will considerably change the way you work with people… or… at least, consider them.

My Favorite Quotes from “DRiVE” by Dan Pink

[Caveat to these quotes: Without some context, some of the quotes lack the BOOM they could have. You just have to go out and buy the book 🙂]

“The performance of the task, provides the intrinsic reward… The joy of the task is its own reward.” – On Motivation Theory from Harlow [Page 3]

“Human beings have an inherent tendency to seek out novelty and challenges, to extend an exercise their capacities, to explore, and to learn.” – On Motivation Theory from Deci [Page 8]

“The underlying assumption about human behavior was simple and true (50,000 years ago). We were trying to survive.” – On Motivation 1.0 [Page 16]

“That first drive (Motivation 1.0) didn’t fully account for who we are. We also had a second drive – to seek rewards and avoid punishment more broadly.” – On Motivation 2.0 [Page 16]

“Economics isn’t the study of money. It is the study of behavior. We are constantly figuring the cost and benefits of our actions and then deciding how to act.” – [Page 24]

“People are irrational – and predictably so.” – Dan Ariely [Page 25] Continue reading “Book: DRiVE – Daniel H. Pink Quotes”

Woman in Leadership – Top Women in Agile Thought Leadership


[Click the image on the right for a full size infographic of the growing numbers of women leaders!]

I am very happy that women in leadership is growing. Having both sides of innovation and thought leadership from both males/females will create more dynamic environments that will product better products. I believe it!

I am truly excited that slowly but surely my RSS feeds are growing from women in management and executive positions. There is a TON of great stuff to read by women in leadership.

What I’m even more excited about is how my RSS feeds are growing to include female developers/coders and fellow nerds/geeks alike. I have a daughter and my hope is she will love technology (code?) as much as I do!

Here is to a better future!


[In no specific order, according to my RSS feed, and who update frequently]

Interestingly enough, most of the women stated here are also part of the [Top 200 Agile Blogs] as well (make sure to check that out). Congrats!


Grab either badge if you’re a woman blogger and link to this post! Show your pride! 🙂

I am SURE I missed some other women leaders. Please let us know in the comments!

Retrospective 61 – #PMI #Agile Exam and #LeanGiving

  1. True LeanGiving at it’s best 
  2. Working hard, or hardly
  3. PMI-ACP Exam explained – Tips and Tricks
  4. UpstartHQ – Kanban Tool
  5. Impediment Monkey – A tool to track issues
  6. Top 50 Managament Gurus


LeanGiving in the Real World – Agile for Mechanics

[Guest Post – MJ Wivell is the CEO of BTI360 and is known as a thought leader in implementing Kanban systems to manage software teams. MJ holds a B.S. in Computer Science from Lynchburg College and a M.S. in Informations Systems from George Mason University. MJ is a Sun Certified Java Programmer and Certified ScrumMaster]

Recently I met Peter Saddington at AgileDC and he asked a simple question:

What if our organization was to take your talents and use them to bless others?

Peter called this LeanSalt/LeanGiving.  That question rang in my ears.  And then it happened, spontaneously.

Two days later I was working with a software team one of the project managers had a puzzled look on her face.  She said, “I think this agile stuff would work great in my husband’s automobile company.”  Immediately I thought of Peter’s question.  Here was my chance.

I learned that she thought there was a lot of waste in the company and if improvements could be made more cars could be worked on which meant more revenue for the shop.  The challenge was where to start?

After a lot of conversation we decided to implement 3 changes:

  • Visualize the work flow and limit each mechanic’s work
  • Have nightly check-ins to plan for the next days work
  • Conduct retrospectives at the end each week for continuous improvement


Once we visualized the workflow and limited the amount of work in progress, issues started to bubble to the surface.

  1. First, expert mechanics were doing low cost, routine jobs like oil changes instead of high performance jobs that brought in more revenue.
  2. Second, mechanics spent overhead time ordering parts (instead of the service manager) rather than revenue generating time working on cars.
  3. Third, a large backlog of cars were stacking up waiting for a mechanic to become available.

The following were the solutions the team suggested at the daily stand ups and retrospectives.

  1. Focus expert mechanics on high paying, high performance jobs.
  2. Let the overhead staff (service manager) handle overhead tasks.
  3. Visually track each car in the work flow to better manage customer expectations.

These changes led to greater team morale, customer satisfaction, and profitability.

Change the World. Help Others.

It was all capped off when the project manager came back to me and said, “Last night for the first time in months I saw my husband smile about the business.”  Wow!

So, how can your organization take its talents and bless others?  Who knows, you just may change their world!

Working Hard? Or HardlyWork.In?

Need to check your facebook at work? Have no fear! Read your facebook updates and look like a pro… an excel pro!

[Enter]: HardlyWork.In

Yep. You’re entire facebook experience in a spreadsheet. Fear not the command-and-control boss. He’ll walk by your desk and smile, because he knows (thinks) you’re hard at work.

Oh wait! He’s coming back. Press your spacebar and… wah-la! Boring numbers pop up. You are truly an epic corporate employee. Grab yourself a mountain dew. This is going to be one helluva day.

[HT: HardlyWork.In]

PMI-ACP Exam Explained – Tips and Experiences Taking the Agile Certified Practitioner Test

It was FREEZING in this Test Center

I just completed the PMI-ACP (Agile Certified Practitioner) exam at a local test taking facility.

Facts about my test taking experience:

  • I was initially accepted into the PMI-ACP exam pilot in June, 2011.
  • I received countless emails about my need to take the exam soon.
  • I ignored them all until the last possible minute.
  • I paid my dues and signed up for the exam on Monday, November 28th, 2011 at 9:03PM.
  • I took the test on the last possible day, 2 days later on Wednesday, November 30th, 2011 at 12:45PM.
  • The test took me 2 hours, 10 minutes (approx).
  • I completed my first pass of the test within 45 minutes.
  • I completed my first review of my answers within 35 minutes (because I like to be thorough).
  • I completed my 3rd and final review of my answers in about 30 minutes (because I wanted to have material to blog about for this post).

Tips on what to know (because you already know it anyway):

  • Fully understand the principles and practices around Agile (including estimation, prioritization, and team dynamics) ~50 Questions
  • Fully understand the Scrum roles (ScrumMaster, Product Owner, Team) ~25 Questions
  • Fully understand basic Scrum ceremonies and artifacts (Sprint Planning, Release Planning, Retrospective, Reviews, Burndowns, wallboards, backlog management) ~25 Questions
  • Understand the foundational elements of XP (Extreme Programming) ~10 Questions
  • Understand Agile Value Stream Mapping stuff ~5-10 Questions
  • Understand Agile Portfolio Management ~5-10 Questions
  • Understand Agile Risk Management ~5-10 Questions
  • Understand some Lean Software Development stuff ~5 Questions

What not to worry about:

  • Buying all 12 of the books on the PMI reading list. If you’ve been doing Agile, you probably own a couple of these anyway (Full disclosure, I own 8-9 of them).
  • Crystal, FDD, DSDM – Not in the test.
  • Scenario questions – They are easy. Use your noggin… or noodle.
  • Doing super complicated formula stuff. I seriously expected to have to solve some Earned Value Management questions like utilizing formulas: PV=(FPV)/((1+IR)^N) and NPV= -COST+(Income)/((1+DI)^N)… and so forth. I guess it’s just the engineer in me.
  • Also, I seriously thought that we’d be jumping into some deep analysis of Agile methods… don’t know why I thought this…
  • I did think there was going to be more … how do you say… engineering ideas and practices in there (devOps anyone?). But don’t worry. There isn’t. Continue reading “PMI-ACP Exam Explained – Tips and Experiences Taking the Agile Certified Practitioner Test”