Friday, November 19, 2010

French Fries! (important and fun team habits)

I work in a company that values work/life balance. This means that when people need to work from home for a good reason, they do. But this in turn means that they have to dial in for our standup and other meetings that day. Sometimes, it is hard to hear on the phone from home, especially when 3 people in the meeting room are looking at each other and talking over one another.

"FRENCH FRIES!"

Yeah, that would probably get your attention if someone yelled it out in the middle of a meeting, wouldn't it? Well, that's the phrase that the team created for our standup to state... "hey guys, you are making it impossible for me to be an equal member of this discussion; or even follow along". This is typically caused by people talking at the projector screen instead of the phone (too quiet), but it has other good uses also.

It's a silly phrase. It might seem unprofessional to some... but it's part of our culture. (Don't ask how we came up with the phrase, I honestly don't remember.)

My point?

Have fun in your team. Find ways to help the chemistry of the group work. Make sure people respect each other, and provide ways for them to communicate feedback in a constructive way.

The other day, a higher level manager yelled French Fries in a meeting where most people in the room hadn't heard it before (not people in our standup). It made me laugh because it shows that the idea is effective and is spreading.

Monday, November 8, 2010

Buy a Feature - How poker chips can help with planning

Today I ran an exercise some call the "Buy a Feature" game. It's a very simple but valuable approach to brainstorming an area and building a backlog.

We had an area of our system that we realized we had let lapse over the last few years. We'd focused so much on wringing profit out of the engine that we'd lost sight of the fact that our core feature had been left behind in comparison to our competitors. For the sake of not ticking off my employer, I'll not name the feature here.

Here's an overview of how we tackled the problem:

We collected the stakeholders together into a room. This included the CEO, those tech folks with the most insight and history of this area, and the representatives/advocates of the users of this feature. I facilitated.

  • Step 1 - Collection - Everyone wrote ideas (features/stories/backlog items) on an index card. They read it aloud and put it on the table for everyone to see. We did this round robin until everyone felt they had made a good list of ideas to improve this area. It helped greatly that everyone came to the meeting with a list pre-authored.
  • Step 2 - Refactoring - We took a moment to look at the list and group or break up items that overlapped. We wanted to insure that items were stand-alone. We also wanted to make sure that items that would be built together (because they had to be), were prioritized together.
  • Step 3 - Buy a feature - I gave everyone in the room 10 poker chips (it was a list of about 25 items) and said they could put all the chips on one item, or each chip on a different item. They should "spend" their money as they saw value.
  • Note: We could debate whether everyone's money was equal (example: the CEO's?) but you'll see in the following step that this didn't turn out to matter. The goal of this exercise was to get to consensus within one hour.
  • Step 4 - Tally and Discuss - The features with zero chips were grouped and quickly confirmed as good ideas for a future release (not right now). The features with a large pile of chips were grouped, and the team agreed that they were not worth debating since it was easy to agree that they had to be built soon regardless of cost. This simple approach kept us from discussing any of the items (cost, design, etc) where we all easily agreed on the outcome. One of the big things I see when facilitating teams is that they spend time discussing the wrong things and never get to the tough stuff.
  • Step 5 - Repeat - For all the items in the middle band of votes (they were all chip piles of 2-3), I gave out another 5 chips to each person and had them spend on only those. This provided the same outcome, but only on the middle set from the first round.
  • Step 6 - Close - We got really lucky. I color-coded and sorted the list in an excel spreadsheet (documenting the meeting) and asked the team if they had issues with it or supported it. Amazingly, the group agreed that the list made complete sense. I proposed that this "mini-backlog" be a project, that the top band was in, the bottom band was out, and the middle band was scoped based on the estimate that came back from high level design. Again, the group agreed and we were done with our meeting in an hour.
So... in one hour we took a team of people and tackled this problem. We came out with a release 1 backlog for the project and knew exactly where to go next. I have to say it is the quickest we've done this. Normally we spend a lot of time discussing and we run out of time before we can prioritize and agree.

What was the one thing I'd do better next time? I'd have a different color poker chip for each person so that they could move chips around if they changed their mind. People couldn't remember where they had placed, so they couldn't easily move their chips... although this could be good and bad.

Have fun with it... the tactile/physical interaction from this definitely aided the exercise.

Saturday, August 14, 2010

Agile 2010 Wrap-up

Unfortunately, I was only at Agile 2010 for Tuesday and Wednesday due to family obligations. But, I was able to catch up with a lot of people during that time and take in a few really good sessions. I also presented a session myself (see prior post) and I got some really positive feedback. Below are some of the notes I took from some of the sessions I attended.

Dave Thomas' keynote on Tuesday
  • When you are certified, you are useless, you just now have the body of knowledge in your head but it takes 10-30 years to learn how to use it.
  • Certification does not provide confidence... this is what craftsmanship can overcome.
  • Practicing leads to sub-cognitive action and muscle memory.
  • You have a QA team because you didn't care enough at the beginning.
  • If you can't do it with an index card, then you can't do it with fancy tools.
Effective Questions for an Agile Coach by Arto Eskelinen and Sami Honkonen
  • Coaches exist to create awareness and responsibility.
  • Don't inflict advice, ask questions, invoke change
  • Good coaching questions cause exploration (what, when, how much, how many), aim at a descriptive answer, avoid judgment (how, who, why), and avoid an unproductive state of mind
  • When tackling problems, use the G.R.O.W. approach (Goal, Reality, Options, What to do)
  • Goal - describe desired state, insure it is high enough of a bar, be positive, be meaningful (what's in it for me), be specific
  • Reality - are assumptions tested, explore different angles, expose feelings
  • Options - existing ideas stated, limitations challenged, "stupid" ideas discussed
Great quote from a session when a team member was distracted - "I'm sitting out for this because I'm in the middle of deploying software... for the president... no... the President of the United States... yeah, we're waiting for Barack to login and accept the deploy." Yeah, he was serious!

Another great quote - "worst level of management" defined as "far enough away they can't help, but close enough to interfere".

Hiring doesn't have to be Random by Rod and Arlo Belshee
  • Hiring is the most permanent change you typically make in your organization
  • It's expensive
  • Candidates have skills (learned), traits (personality), and behaviors (reflections of traits).
  • Focus on traits by interviewing for behaviors
  • Behaviors are data points for proof of traits you want (they can lie and say they have certain traits, you need examples, the more specific, the more real)
  • Best assessed by doing, have them code during interview process
  • Before interviewing assess your team for what traits they have. Determine what is required for a new person to fit in, and what you are missing that you need to find in a new team member. (What do you value - must haves, what do you need - additive.)
  • Focus less on skills, this can be taught.
  • Avoid labels, these say more about the interviewer than the interviewee and can lead to legal issues.
  • "If you missed it in college, I can train you on the job, if you missed it in kindergarten, not my problem"
  • Your team is a system with behaviors within a context. You can modify that system.
  • Add a reinforcing capability.
  • Balance out an excessive trait.
  • Fill in a missing trait.
  • Put the interviewee at east so you can collect data. Gang/Panel interviews don't do this, they could destroy your data collection.
  • Why isn't your team talking about and defining what the team needs in a new hire?
Arlo's story about problem solving (and measuring level of problem complexity):
  • A one beer problem is when you and another person go to the bar and drink a beer and quickly uncover the solution.
  • 2 beers may help.
  • Sometimes, it may take up to 5 or 6.
  • After 6, it is clear that you need a higher distillation level.
  • Try whiskey, it requires you to pass it around and share it (problem solving included).
  • After 6 shots of whiskey, if you haven't solved the problem as a group, it's clear that additional alcohol isn't going to provide the necessary clarity.
  • Time to switch to narcotics!!!
  • Wait, maybe that's a sign it should be left to the professionals...
It was a great conference, as always, maybe next year I can present again and stay for the whole week.

Monday, August 2, 2010

Agile 2010 Talk: Agile Transitions- Cannonball and Stealth Approaches Exposed/Compared

Description: You've discovered agile and are excited! You are a leader within your team or company. Your next question is "How do I ignite this fire and get agile to take root in my organization?" After experiencing two extreme opposite transitions, I will tell the story of these approaches along with their successes, failures, and lessons learned. One transition occurred in a regulated global 50 company including offshore teams which dove headfirst into Scrum and XP within 3 months. The second is a stealth transition in a small .com startup company that is still ongoing after 3 years.

Time: Wednesday, 11 August 2010, 11:00 - 12:00

I've finished my slides and just have to do a few practice runs. If you are interested in this topic, then I'd really love to have you in the audience! I'm going to set up the talk with an overview of the two company environments and how each affected the potential of an agile transition. I'll then tell both stories, and end with the lessons learned from both. I've put a lot of planning into this one, so it will definitely be one of my best talks yet!

Wednesday, June 30, 2010

Startups are agile by their nature?

Yesterday I had the privilege of presenting the topic of Agile to the portfolio of new companies being mentored by a company called DreamIt Ventures in center city Philadelphia. It's a great program, and I'm proud to have taken some time to support it. I'm sure that some of these smart folks will be successful.

The interesting thing I noticed when walking through their space was how they worked. Each "company" was a group of 2-4 people sitting around one table next to wipe boards filled with thoughts, requirements, plans, etc. The energy levels were high and everyone was focused on the short time they have together to ship this new product and form the foundation of a future company.

One of the disadvantages to selling the agile philosophy to this type of audience is that they aren't overcoming a legacy of problems. Instead of talking about the "downfalls of traditional management" and sucking them into the "wonders of agile", you have to focus on a completely different issue. Instead of saving them from their past, you are instead trying to save them from their future.

It's almost like startups are agile by their simple nature! And it's our job to point at the things they need to protect as they grow (team culture). We have to point at the guardrails they should put into place today before they are too large to recover (examples: focus on technical debt and backlog management). Their team behavior is such that they "just do stuff".

It's very similar to the environment I'm in now. It worked well under 30 people. But when my company grew to 60+, suddenly we needed some process. So, what does all this tell me? It tells me that it's time to start working on those slides for Agile 2010, because this is the exact topic I'll be talking about (Agile Transitions). See you then!

Tuesday, June 22, 2010

Update on me & 3 things that motivate people...

I know I don't blog much anymore, it's mostly due to my shift in technology and daily focus. Twitter, Facebook, and other realtime environments have become much more immersive ways for me to interact with people. Also, I'm more focused on action than talking/sharing now. I still share via Twitter, but I'm more active in coaching and evolving process at work, and I've picked up a few speaking engagements. A few months ago I did an Agile talk at a local PMI chapter, in a week I'm doing another in downtown Philly for a portfolio of startup companies sponsored by a mini-VC. In August, I have the privilege of speaking at Agile 2010 (I really need to get on those slides!). These are smaller audiences, but it helps me connect with people that I can interact with and provide something of value immediately. So, if you need something like that and are near Philly, feel free to contact me (kschlab [at] gmail [dot] com).

But I will still share great stuff when I see it! Below is a great video about motivating employees and the negative impact of cash incentives. This has been a recurring theme in the culture/team discussions within agile for years (Linda Rising, Diana Larsen, Mary Poppendieck all come to mind), but it's a good research driven summary. Check it out:

Thursday, March 25, 2010

The team is too fast, what to do?

During a recent conversation in a LinkedIn group, the following question came up:
Assuming you are maintaining a high velocity but your customer isn't keeping the pace with the team in-terms of feedback and freezing the stories. what do you do? Do you decrease your velocity or keep the pace and develop things based on your assumptions?
My response:
Talk to your customer. If they are happy with the pace, then you could downsize the team to match the customer velocity and use those resources elsewhere.

If they would love to go faster, then work with them. Learn how to help them be a better customer, or immerse some of your team in the activities of the customer (slowing your team down and speeding them up).

View the customer as being part of the team, at least until you can solve the problem.

The goal is not to develop stuff fast... the goal is to deliver the right stuff fast. (therefore developing things based on assumptions won't help).

Another thing you can do with that "extra time" is reduce technical debt, train the team on new stuff, refactor code, and improve things like performance and installability.
Your thoughts?

Friday, March 12, 2010

Keep your stinkin' Maturity Model - prescriptive vs. adaptive

I keep seeing the same question appear in many forums lately- "How do we create a CMMi-like Maturity Model for Agile?" Sometimes this is a global question for the community, sometimes it is a question focused on a specific organization.

A couple of thoughts:
  • Not all problems can be solved by the same solution
  • Not all teams have the same problem
  • Not all teams have the same dynamic and ability to change
  • Thus, not all teams will succeed with the same set of instructions
  • But, all teams can be aided by an experienced mentor/coach
Whenever I hear of Maturity Models, I foresee an environment where the desired process is documented and stable, and the steps to evolving to it are prescriptive, standardized, and audited.

The problem I have with this is that it will most likely constrain the teams ability to explore new ideas and solutions to their problems. Their continuous improvement will most likely be driven through a canal that is managed by lock keepers and limited to the waterway. Kanban has had a refreshing influence on the community, but it is not for everyone. Does an organization create a maturity model that takes in every new idea? Does it have the capability to create a choose-your-adventure pathway?

Yes, I think an agile transition maturity model is possible. But I also think it is improbable to have the right outcome. And, it might be less work to allow the teams to find their own way with a centralized coaching/mentoring staff. What do you all think?

From a recent LinkedIn conversation I was having:
I would suggest that a first step is to inspire the PMO group in your organization to get out and observe the teams. Start documenting patterns. When there is a catalog of "for this problem, here are solution patterns that have worked", you not only have teams learning and growing from each other, but teams of like need mature towards a converged point.

Personally, I'd prefer this over a CMMi approach because it is a mentoring/guidance solution instead of a prescriptive/directed solution. The minute you demand teams follow a certain path, you limit their ability to explore and uncover great ideas. I believe that creativity and exploration through retrospectives is a key part of continuous improvement.

Why use the term coach?

In my work, I've had many labels applied to me. On bad days, they may not be so pretty; but most days, they are terms of endearment for what I try to provide the people I work with.

Recently, I got in a discussion about these terms and why "Coach" was the best term (other terms included: shepherd, evangelist, guru).
Coach is a great term because a coach is a person that is invested in success/failure (winning/losing), but isn't normally on the field doing the work. Their job is to provide the mentoring and tools (and environment) for the team to be able to succeed. They rally the team when they are down, and they point out the obvious when the team won't face it. They uphold the team values, and drive them to continuously improve. Finally, the focus is never on the coach, but the team's performance.
This is true in sports, and is true in agile environments.

Wednesday, February 10, 2010

Book Review: Agile Coaching (Davies/Sedley)

Due to the second part of the Snowpocalypse here in the Northeast (3-4 feet in less than 7 days!), I had the opportunity to work from home and catch up on some reading.

The first selection was "Agile Coaching" by Rachel Davies and Liz Sedley. This book is part of the Pragmatic Programmers publishing series.

This is a great book with lots of modern concepts included. I was surprised to find notes on Kanban and Pomodoro included in sidebars since these concepts just became common/mainstream knowledge in the community in the last year. As a whole, the flow of the book and the ideas contained were well-organized and easy to absorb.

My only disappointment with the book is that I was hoping for a whole book on improving as a coach, but this was limited to the last chapter. The majority of the book was focused on various slices of agile and how to facilitate them. Because I was lucky with my entry into agile (I was mentored by great coaches from ObjectMentor), many of these thoughts had been planted in my head years ago. It was good to refresh them in a simple condensed fashion though.

Summary- I'm glad I have this book in my library. It may not have provided new information for me, but it is a great reference in times of stress when teams slip back into old habits. It provides a great reminder for me of things that I sometimes forget. More importantly, the book can be read in slices which makes it a great tool to hand to others to learn a specific concept. I think target reader should be anyone new to agile that is in a leadership role (note I didn't say management). I have a strong feeling that I may use this book heavily as a tool to provide insight for others.

Thursday, January 21, 2010

Scrum is the "only sane, rational way to manage dynamic processes"

So... let me start with the setup. It was asked in the Agile Alliance LinkedIn Group whether the agile community is mature enough to coherently discuss a "maturity model". I was one of the first two to respond that answered down similar lines-
Mature enough, yes. Coherent, no.

Agile is a philosophy and culture. It is an umbrella term for a set of best practices... Scrum & XP being only two. I believe that getting everyone to agree on an AMM will either destroy the continuing evolution of the movement or marginalize non-core movements that are adding to it (think of Kanban/Lean in the last year).
The discussion continued on an interesting path including CMMi and other maturity models, the pro's and con's and various gut reactions to what this would mean. All good stuff.

But in the middle of this, Melvyn Pullen and I got on a tangent that started with him proposing an agile maturity model that was focused solely on Scrum for the first few steps. I questioned this since agile has many flavors, and enforcing Scrum as the first step seems limiting.
The problem I have with a maturity model defined this way is that it implies to all newcomers that it is the ONLY way. The manifesto was signed by 17 people of 7 methodologies/practices. They didn't identify Scrum as step 1 down that journey.
He responded with,
I believe that Scrum is the only sane, rational way to manage dynamic processes.
and
It is my opinion that Scrum is the only management technique that comes from the agile camp that could be used to introduce other agile processes.
Comments?

Agile books to read...

A post was put up in the Agile Alliance requesting books to read to learn about agile. This was a pretty wide scope, and it resulted in a pretty broad list that continues to grow:
Authors and topics-
  • Kent Beck (XP, patterns)
  • Mike Beedle (Agile, scrum)
  • Arie van Bennekum (Agile, DSDM)
  • Alistair Cockburn (use cases, crystal, etc.)
  • Mike Cohn (agile, scrum, planning poker, etc.)
  • Ward Cunningham (XP, patterns)
  • Martin Fowler (enterprise design patterns, refactoring, uml, xp, etc.)
  • James Grenning (planning poker, etc.)
  • Jim Highsmith (time-boxing, agile development)
  • Andrew Hunt (pragmatic, incremental development)
  • Ron Jeffries (XP, etc)
  • Jon Kern (agile development and PM)
  • Craig Larman (Craig's been writing about IID/Agile for a long time)
  • Brian Marick (I think agile testing - but I'm not familiar with his work)
  • Robert C. Martin (Agile Principles, Practices and Patterns, etc.)
  • Steve Mellor (not familiar)
  • Mary Poppendieck (lean)
  • Ken Schwaber (co-founder of scrum, buy all of his books)
  • Alan Shalloway (design patterns, agile, lean+scrum, etc)
  • Jeff Sutherland (co-founder of scrum)
  • Dave Thomas (agile OOA/D)

Credit for this list goes to everyone that helped build it on the forum.

Wednesday, January 13, 2010

Is Agile a more humane way of working?

This was the question asked in the Agile Alliance LinkedIn group, and the question was focused on agile vs. other methods. It questioned whether the manifesto itself was written with the human element in mind, or whether it was focused on efficiency and outcome only (the human element being a byproduct). Additional points mentioned the 40 hr work week (as opposed to more) and sustainability.

The first three responses dissappointed me since they were non-answers.
  1. I wasn't there, we can only guess (as if we've never heard the authors speak since then!)
  2. I'm not sure, but it is at least more natural
  3. Self direction creates a perception control and therefore happiness
Not being one to sit idly when there is an obvious answer, I had to state the following:
Yes!

The 8th principle of the Manifesto - "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely."

BTW, many mature XP teams will peak around 35 hours, not 40. Pairing and TDD is very intense. You get the most around 35 hours, and productivity can start decreasing between 35-40. But this productivity is higher than the prior 45-50 hr weeks. I've both seen this and heard about it from others.
Cesario Ramos chimed in also:
The lean and agile thoughts explicitly make human values to be the center. It promotes an environment where every individual can use its potential for developing itself and its company. An environment where people can be part of a team and can contribute to a higher objective.

So in my opinion, YES, it is a more humane way of working. Even if the intentions of the agile approach are just to make more money.
There is that caveat that every idea can be destroyed and that there are plenty of companies that use Agile to get more hours out of their people. But, when I see this, I tell those that are suffering that their pain is inflicted by people, not by trying agile (and they aren't doing agile)!

Saturday, January 9, 2010

My Overview of Agile Presentation (to a local PMI Chapter)

I was invited to give a talk about Agile to the Delaware Valley PMI Chapter on January 7th. The audience was going to be filled with local PMP's, some of which would be skeptics, and some of which would have been burned by bad agile implementations. I was worried about how to normalize their knowledge, and I had to do it in less than 45 minutes so there was room for Q&A.

Once I realized that I couldn't cram Scrum, XP, Lean training in along with a proven case study... I decided to go for the overview and provide them what they needed to find out more. I wanted the group to understand the Scrum is Agile, but Agile is more than Scrum.

As far as I can tell, the session was a success. I got positive feedback at the end, and I felt I made the most of our time.

If you want to get a copy of the slide deck, you can download it here. Since I'm not that popular of a guy yet, hopefully this won't overwhelm the daily bandwidth limits of my personal website traffic restrictions. If you get nothing, email me or put a comment on this post and try again tomorrow (and I'll have to move it to another host).

Having been through this experience, if there is anyone in the Philadelphia region that is interested in having me come talk about Agile or some specific piece of it... feel free to contact me. You can find many ways to reach me on my personal site.