My Work Manifesto

I've found that people can play in the same field, doing the same activities, even using the same words, but have vastly different motivations underneath. What motivates us isn't always openly discussed, but it's clearly evident when when I'm in a discussion with a new friend, some colleague my area of work, and I feel a connection on a deeper level. This becomes more of an issue when a business sector is having success and some come into that area simply for that reason. That is, most people I've met in art or landscaping do so because they are passionate about it, not because it will pay for a home in Newport Beach and a new Lexus (while they might appreciate and get those material things, that is not their primary motivation).

Admittedly, I've struggled with how I feel about this with each new agile company I see or coach I meet. I ask myself, "Were they passionate about agile before this recent boom?", but I've also had to ask myself if that matters. Would it be okay, with me, if they weren't passionate about agile and were only in it for the money? What if they were good at coaching, training or in other ways helping companies and people? What if they become passionate about it? Those questions, and more, are ones I can't answer and, I've found, that I cannot decide the worthiness of others being in this field. I can only look at myself in the mirror and refine what's there.

To this end, I put together a list to help me determine my guiding values and, as the Agile Manifesto does, did so in a comparative manner. May it be of some help to you.

Purpose-Motivated over Money-Driven
Extending the Vision over Keeping to the Familiar
Stretching Myself over Staying Comfortable
Helping the Whole over Benefiting a Few
Abundance Mentality over Scarcity Mindset
Others' Needs over Self-Interest
Giving Back over Accumulating
Making a Difference over Busyness
Significance over Success

That is, while it may be fine for others to value the items on the right, I value the items on the left more.

Goals for Agile Teams

When working with companies who are trying to adopt, or correct, an agile approach to their projects or product development, usually using Scrum, the situation, needs and specific problems vary. But the core needs, and root cause of problems, doesn't typically vary that much.

With that in mind, I have a few goals that help me stay focused on the "main and the plain" of agile, and begin with the end in mind (to borrow from Steven Covey).

My Goals for New Agile Teams :

1. That they know, understand and practice the Scrum framework
2. That they are aware of where they aren't, the possible consequences, and the limitations (domain) of Scrum
3. That they know, understand, and are living the agile principles, Scrum values and self-organization
4. That they are aware of other agile methods and the pros and cons
5. That they are connected to community and learning sources
6. That they gel and are moving forward as a team
7. To understand why management wants Scrum/agile here
8. To know their definition of success
9. To understand what they see as their opportunities and challenges

And my personal goals when coaching agile teams:

1. That I set and meet expectations each week
2. That goals are stated and progress visible
3. That goals clearly align with my customer's goals
4. That I understand what it means to meet and exceed expectations
5. That I understand what will help them move forward, and have contributed to that

Technorati Tags: agile, scrum, project-management, coaching, eds-pick, business

Kanban Book Review

I just finished reading Kanban and Scrum - making the most of both, by Henrik Kniberg and Mattias Skarin. You can download it for free. I was very impressed by this self-published book, enough so to place an order today on Lulu for a paperback version.

Despite my readings of blogs and listening to podcasts on Kanban, it still wasn't clear to me. Knibert and Skarin broke it down so clearly for me that I finally got it. They took a simple approach, used lots of drawings, as well as comparisons to Scrum that helped related it to something I did know.

Here are some of my favorite quotes from the book:

As teams evolved from individuals to self organizing units, the managers realized they were facing a new set of leadership challenges. They needed to deal more with people issues – handling complaints, defining shared goals, resolving conflicts, and negotiating agreements.
...
The WIP limits are there to stop problems from getting out of hand, so if things are flowing smoothly the WIP limits aren’t really used.
...
The only thing that Kanban prescribes is that the work flow should be visual, and that WIP should be limited.
...
What should the Kanban limits be?
When the Kanban limit for “your” column has been reached and you don’t have anything to do, start looking for a bottleneck downstream (i.e. items piling up to the right on the board) and help fix the bottleneck. If there is no bottleneck that is an indication that the Kanban limit might be too low, since the reason for having the limit was to reduce the risk of feeding bottlenecks downstream.
...
If you notice that many items sit still for a long time without being worked on, that is an indication that the Kanban limit might be too high.
•    Too low kanban limit => idle people => bad productivity
•    Too high kanban limit => idle tasks => bad lead time

...value stream map. It’s basically a visualization of the value chain and provides insight into work states, flow and time through the system (cycle time).

Over time, managers learned that if they kept number of concurrent projects low, they didn’t keep stakeholders waiting.
The need to project delivery date was no longer a big issue. These lead managers to stop asking for up front estimates. They only did if they feared they would keep people waiting.

And I particularly loved this approach with management, and of course their results overall:

But keeping traction on complex, infrastructure type issues was a harder ordeal. To deal with that we introduced the ability for teams to assign up to 2 “team impediments” to their managers.
The rules where:
1. Manager can work on two slots at any single point of time.
2.    If both are full, you can add a new one as long as you remove the less important one.
3. Team decides when issue is solved.

Three months after introducing Kanban, the system administration team was awarded “best performing team” in the IT department by the management. At the same time, the system administration team was also voted as one of top three “positive experiences” in the company retrospective. The company retrospective is a company-wide event that happens every 6 weeks, and this was the first time that a team turned up on the top 3 list! And just 3 months earlier these teams had been bottlenecks that most people were complaining about.

For those trying to learn about Kanban, or those responsible for leading, coaching and/or training Scrum in your company or for clients, I highly recommended this book.

Technorati Tags: agile, kanban, lean, scrum