Using Kanban to run your start-up aka Stephen Covey was the first Agile Coach

Using Kanban to run your start-up aka Stephen Covey was the first Agile Coach

Honolulu has a thriving startup community. I decided to present on this topic after attending the kickoff of the extremely popular start-up event, Honolulu Startup Weekend. While listening to the pitches, I realized that these potential new companies were ripe for some Agile basics. Many of them were already very familiar with Lean Startup and customer driven business development, but very few were familiar with the Agile techniques designed to manage day-to-day projects or business.

I like to consider Stephen Covey as the first true Agile coach. His 7  Habits of Highly Effective People addressed key  effectiveness techniques that align nicely with Agile. My favorite one is First things First,  "To live a more balanced existence, you have to recognize that not doing everything that comes along is okay. There's no need to overextend yourself. All it takes is realizing that it's all right to say no when necessary and then focus on your highest priorities." This is perfectly aligned with the Agile Manifesto principle, "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

One of the techniques he uses for First Things First is to get people to understand  the difference between urgent versus important work. He wasn't the first to make this distinction, Dwight D. Eisenhower is credited with this quote: "What is important is seldom urgent, and what is urgent is seldom important."  What Covey is responsible for is the creation of the following time management matrix to help people distinguish where they are spending their time:

  • Quadrant 1 is for important activities you could not have foreseen, and others that you left until it was almost too late. Plan for these.
  • Quadrant 2 is for important activities that help you achieve your personal and professional goals, and complete important work. Focus here.
  • Quadrant 3 is for time-sensitive distractions. They are not really important, but someone wants it now. Learn to say no.
  • Quadrant 4 is for activities that are just a distraction. Avoid them if possible.

The intent of this matrix is to get people to focus on daily activities and plan their time within Quadrant 2. At the time of publication (1989), the most common technique for managing your time spent on important activities was to capture them in your calendar book. This was before phone apps or even the use of Outlook calendars. They were documented in those heavy DayTimers calendars that people carried everywhere. Covey's training courses suggested that you block time in your calendar to focus on important tasks and limit the time you spend on urgent tasks.

This fits nicely with Agile prioritization approaches and managing WIP. For the purpose of the audience last night, small business owners, I compared this approach of managing your important work in your calendar to the Kanban concept of prioritization using of classes of service and managing work in progress (WIP). I personally use this approach to manage my business every day. I have an online Kanban board (LeanKit) with swim lanes of important activities and I have WIP limit of a minimum of 6 hours of important work each day. I assume that at least 2 hours of my day will be taken up with unplanned urgent activities. I also use the Kanban Board to capture a backlog of ideas that may eventually become actual work. Here is an example of my business-oriented Kanban board:

Kanban

For those of you familiar with Agile techniques, it is easy to see how these techniques can be applied to many different situations other than software project management. I also believe that there are very few new ideas in Agile since these effective management techniques have been around for many decades and are just now being embraced within traditional project management. If Stephen Covey was a software developer, he would have made a great Agile coach.

For more information Kanban, check out my blog post or listen to my Introduction to Kanban self-study training.

References:

About the author, Dan Tousignant

Dan is a lifelong project manager and trainer with extensive experience in managing Agile software development projects. Though the role of the professional project manager is changing dramatically through these approaches, Dan coaches organizations on how to transition teams and organizations to Agile.

Dan has over 20 years of experience providing world class project management for strategic projects, direct P& L experience managing up to 50 million dollar software development project budgets, experience managing multi-million dollar outsourced software development efforts and strong, demonstrated, results-driven leadership skills including ability to communicate a clear vision, build strong teams, and drive necessary change within organizations.

Dan holds a Bachelor of Science majoring in Industrial Engineering from the University of Massachusetts, Amherst and is a Certified Project Management Professional, Professional Scrum Master, PMI Agile Certified Practitioner and Certified Scrum Professional.

Dan Tousignant, President

Cape Project Management, Inc.

http://CapeProjectManagement.com

https://capeprojectmanagement.learnupon.com/store 

Please follow and like us:
Does your organization need an Agile Coach?

Does your organization need an Agile Coach?

As we love to say when answering many questions pertaining to Agile, “It depends.” Not the answer you want to hear, but let me elaborate. Extreme Programming (XP) introduced the term coach into the Agile community. The role was intended to both be a mentor on XP practices and a hands-on developer when needed. Scrum created the role of the Scrum Master with similar expectations but without the emphasis of being a hands-on developer.
The term, Agile coach, has become ubiquitous; however, it hasn't been used as XP intended. Quite often, the term refers to an external consultant and very seldom will you see it applied to an internal position.
I have played the role of Agile coach on and off over the last decade, and I didn’t always use the term coach. I was a coach when I was a program manager of a large Agile initiative; I was a coach when I was a functional development manager; and I was an Agile coach consultant hired to serve multiple Scrum teams. What was common for each of those roles was that I was the most experienced person in the room on Agile practices and I had a passion for passing on that knowledge to the teams I was working with.
In the first two instances, though I wasn’t formally named a coach, it was clear based upon my experience and willingness to share, that people felt comfortable approaching me for advice and discussion. Recently as an Agile Coach consultant, the same dynamic was true, but my role was more formal.

Do I need to be called an Agile coach to be an Agile coach?

Anybody with a passion for learning and sharing Agile best practices can be a coach. Becoming a coach is like becoming a leader. As with leaders, coaches can emerge from within a team.

What skills do I need to be an Agile coach?

  • Active listening
  • The ability to influence without authority
  • Experience – with both success and failure
  • Patience
  • The right attitude!

If they don’t work for me, how can I tell them what to do?

Here is a real situation I faced while coaching a Scrum Master. I had just sat through a very painful Sprint Retrospective:

Coach: “How did you feel that Retrospective went?”
Scrum Master: “It went fine, but the team is bored with them so I try to get them over with as quickly as possible.”
Coach: “Are you open to working with me to prepare something more fun and engaging for the next Sprint Retrospective?”
Scrum Master: “Definitely!”

In this situation, I didn't  immediately tell her what I would do differently, I gave her an opportunity to choose whether she wanted help or not.

How can I be an Agile coach for people that work for me?

I find this situation to be the easiest in many ways. My management style is very much in line with a typical coaching style. I work with the individual on their career goals and set a specific Agile maturity path based upon their experience and role. Some of these goals are around Agile best practices and engineering principles, and most often, it is about soft skills like listening, being self-organizing, and peer influencing.

So, back to the original question, does my organization need an Agile coach?

Every organization that is in the beginning or in the midst of implementing Agile needs someone who can be an Agile Coach. The question really should be, “Who should be playing the role of Agile Coach?”
If the Scrum Master is experienced and has the soft skills necessary, then the Scrum Master is often the coach. If there is a development manager or practice lead with the necessary background and desire, then they can be the coach. A team member can emerge as the coach if he or she has the passion and emerges from within the team.
If none of these internal candidates exist, you may need to look outside the organization—at least on a temporary basis—to fill this role. The ultimate goal is for everyone on the team to have a high level knowledge of Agile principles and practices, so that they can self-organize and continue to improve; resolve impediments; be productive; and truly enjoy their jobs. Then . . . there will no longer be the need for one individual to be a coach.

About the author, Dan Tousignant
Dan is a lifelong project manager and trainer with extensive experience in managing software development projects. Based upon this experience, he has adopted both Agile as the primary method for developing and implementing software. He is passionate about the leadership emerging from self-organizing teams.
Dan has over 20 years of experience providing world class project management for strategic projects, direct P&L experience managing up to 50 million dollar software development project budgets, experience managing multi-million dollar outsourced software development efforts and strong, demonstrated, results-driven leadership skills including ability to communicate a clear vision, build strong teams, and drive necessary change within organizations.
Dan holds a Bachelor of Science majoring in Industrial Engineering from the University of Massachusetts, Amherst and is a Certified Project Management Professional, Professional Scrum Master, PMI Agile Certified Practitioner and Certified Scrum Professional and is the president of Cape Project Management, Inc.

email: dan@capeprojectmanagement.com

Please follow and like us:

Enjoy this blog? Please spread the word :)