Agile Commentary

French Fries! (important and fun team habits)

2010-11-19T11:11:00.003-05:00

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.

Buy a Feature - How poker chips can help with planning

2010-11-08T14:44:00.008-05:00

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.

Agile 2010 Wrap-up

2010-08-14T09:21:00.004-04:00

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.

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

2010-08-02T21:11:00.002-04:00

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!

It's coming! (Agile 2010)

2010-07-21T20:12:00.005-04:00

You can find my presentation summary here.

Startups are agile by their nature?

2010-06-30T16:01:00.004-04:00

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!

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

2010-06-22T10:13:00.012-04:00

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:

The team is too fast, what to do?

2010-03-25T10:13:00.001-04:00

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?

Keep your stinkin' Maturity Model - prescriptive vs. adaptive

2010-03-12T10:26:00.004-05:00

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?

2010-03-12T10:14:00.003-05:00

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.

Book Review: Agile Coaching (Davies/Sedley)

2010-02-10T11:00:00.004-05:00

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.

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

2010-01-21T15:16:00.003-05:00

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...

2010-01-21T14:10:00.003-05:00

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:

Agile Coaching
Agile Estimating and Planning
Agile & Iterative Development by Craig Larman
Agile Principles, Patterns, and Practices in C#
Agile Project Management with Scrum by Ken Schwaber
Agile Retrospectives
Agile Testing: A Practical Guide for Testers and Agile Teams
Clean Code
The Art of Agile Development by James Shore
Lean Software Development by Mary Poppendieck
Making things happen
Tale of Two Systems
The Passionate Programmer
Practices of an Agile Developer
Scrum and XP from the trenches by Henrik Kniberg
Suceeding with Agile by Mike Cohn
User Stories Applied for Agile Software Development

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.

Is Agile a more humane way of working?

2010-01-13T13:22:00.003-05:00

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.

I wasn't there, we can only guess (as if we've never heard the authors speak since then!)
I'm not sure, but it is at least more natural
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)!

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

2010-01-09T19:27:00.004-05:00

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.

We don't want you (yet)...

2009-11-24T08:33:00.003-05:00

The Agile Community doesn't need more people who want to "go Agile"; it needs more people to successfully "be Agile".

I guess this is a follow-up point to my earlier post. We need to stop recruiting and start teaching.

Feed a man fish and he'll be hungry tomorrow. Show a man to fish, he'll feed himself.
Teach a man to teach others to fish, everyone will eventually feed themselves.

.... or something like that.

If you are an organization that makes money getting people to drool over agile and obtain certifications or take classes, but then your students can't successfully do agile... you are a parasite.

If you are an organization that makes money getting people to drool over agile and obtain certifications or take classes, and then your students successfully do agile... you are a teacher.

Subtle difference... are you a teacher or a parasite?
History speaks for itself. Go back and see what people have done in your wake!

The Thumbtack and Hole Metrics...

2009-11-18T09:23:00.006-05:00

Sometimes metrics can just appear in front of you very simplistically without any effort. I've discovered two new ones which I call the Thumbtack Metric and the Hole Metric.

The back story is that we use a corkboard to track our work. This is a high level view of the biggest priorities in VersionOne, our legacy ticket system, and any other queues of work we have. Because our one team supports all company operations AND does new product development, we have a hybrid balance of many different approaches. The board is our central view.

I attempted to force WIP limits onto the board so that it was a true Kanban board, but this simply didn't work in our environment for multiple reasons (nature of our work along with company culture). BUT, it has been very interesting for the team to start realizing when they are attempting to do too much. As the coach, this was something I used to pro-actively point out, but I'm learning that it is better for me to be reactive so that the team themselves can learn from experience. (Unfortunately, a child understands "hot" much better after being burned.)

This maturity and growth has led to many great conversations on the team. They start as individual discussions of philosophy between me and someone on the team, and then they become team discussions where we improve something in our process.

Through all of this, I've noticed a few things that the team now sees after it has been pointed out:

A problem item typically has many thumbtack holes in it (The Hole Metric). The "holier" the item, the more of a problem it is. What is the causation behind this correlation? Well, every week we scrub the board. Every few days rows get re-aligned. If an item is picked up on one day and finished the next... it has one or two holes in it. But if the item gets pushed around for days and lost under other stickies... then it get punched A LOT! So... we now have a metric that can be used to identify areas of improvement. When a "holy" item reaches DONE, it is a good topic for a quick review/mini-retrospective.
Every item on the board needs a thumbtack. We thumbtack stickies so that they don't get blown off while moving the board around (our board sits in a central visible area of the company and is carried into our dedicated standup meeting room every morning). Sometimes we group things with one thumbtack, but in general, there is a correlation between the amount of work on the board and the number of thumbtacks used. I haven't been successful at imposing WIP, but I have been successful in showing that when we run out of thumbtacks, we are in for trouble. This is the Thumbtack Metric. If you need more thumbtacks to stick things onto the board, you have a problem coming (or are already knee deep in it). Conversely, the CEO notices that too many unused thumbtacks might be a sign of available capacity (so I take thumbtacks off the board at times if needed ).

See... all those documents, white papers, conference sessions, etc you've read about metrics... they were overkill. There are simple metrics right in front of your team every day. AND, they are much easier to sell, explain, and use as an indicator moving forward.

So... what's your thumbtack metric?

Agile vs. Traditional Projects... which costs more?

2009-11-12T14:53:00.002-05:00

Another great debate in the LinkedIn Agile Alliance forum... quite a few responses and viewpoints!

The original poster asked the following:

Should Agile Projects cost more/less than waterfall projects?

and the answers varied greatly!

The following focused on whether this was a valid question:

Proving an Agile project is less costly is not easy because your attempting to compare an alternative history -- Clay Nelson

...if we ever start to sell Agile as a way to lower costs then we just invite a a backlash against Agile -- David Nessl

And others attempted to answer it:

Agile does not aim to be a low-cost alternative. Some seem to believe so, but the aim is agility: Speed and flexibility. We become agile to shorten time to market, to increase adaptability and reap greater ROI over the lifetime of a product, to name a few reasons. -- Marcus Widerberg

Agile should cost less for several reasons, among which are: Your mistakes cost less... Earlier opportunities to start getting ROI... Failing early vs Failing late... -- Chuck van der Linden

And of course... my answer:

Most companies do a horrible job of measuring the quality and defect costs that start during the integration/testing/stabilization phases running all the way through support. All companies do a horrible job of measuring technical debt.

If agile reduces these up front, then overall Agile is cheaper from an end-to-end perspective.

But since nobody knows or tracks the cost of these things, Agile (which takes more effort/work to be successful at) will look more expensive on paper.

Tech Example: I can write code without automated tests in half the time, but what will it cost later?

Business Example: I can plan and design everything now, but what will be the cost of unknowns and market changes later when I can't handle it?

Oh, by the way, Forrester Research did a partner study with Thoughtworks... "Forrester TEI concluded our Agile delivery is 40% less expensive overall". - from a Ross Pettit presentation @ Agile East 2009

What if Congress used Agile?

2009-11-10T16:12:00.003-05:00

Eric Camulli posted this interesting question in the Agile Alliance LinkedIn group:

Could Agile help Congress with healthcare reform? I'd like to see someone take a stab at applying scrum principles to the "great development project" of our day...

Our country's healthcare "project" could end up looking like many Waterfall projects...not on time, over budget and not meeting customer's needs in the end.

Unfortunately the conversation quickly started to veer off into moral, ethical, and political opinions/viewpoints/jokes unrelated to agile...

But I thought about this a little bit and I did find some comparisons between our legislative system and large companies that aren't agile. Here is what I ended up writing:

I think the real problem with anything going through Congress is that they don't "go to the gemba". They rely too much on research and lobbyists to translate the needs of the "customer" for them.

Congressman act as if they are Product Owners, but they don't have the domain knowledge or "end user" interaction to truly own that role.

So... I guess my solution is that we need to find a way to decrease the feedback loop distance between those affected by policy and those creating it.

Does anyone else have any ideas or insight into this one?

Individual Recognition on a Scrum team

2009-11-09T14:26:00.005-05:00

Hmmm... another conversation in the Agile Alliance LinkedIn group. Here was the question:

Should we have an individual recognition award in a SCRUM team? Lots of people says that individual award is against an Agile methodology. Award should be given to a team not to a individual team member.

I tried to play a passive role and stated the following:

I have seen these conversations occur many times in many forums and the end of the conversation always results in a "NO" with a very good list of reasons. The risks outweigh the rewards no matter how you set it up.

There is a gray area of disagreement on whether the team can spontaneously award a peer or not. But the minute you make it a regular event, it wanders back into the problem area.

The best reward is taking a respected peer out for coffee/beer and telling them you appreciate their contributions, or saying in front of the team what good they've done. This doesn't need to be organized.

And the first few responses before mine were in line with this:

If you want to have a well jelled team - absolutely not.
The only exception I can think of is if the team requests it.
But that sets up a conflict of interest. - Jay Conne

The only time an individual award is appropriate is if the team wants to acknowledge an individual who has made a significant contribution that made a big difference TO and FOR THE TEAM. - Shane Hastie

But then we got the extremist viewpoint thrown in:

The Communists tried the concept of Co-Operative farming. Under that framework, no individual was supposed to be better than the rest. Needless to say, the concept didn't work out.

So I found myself having to take a stance and state the following:

Here's the best way to summarize what I'm insinuating/feel:

If an award is financially valuable... and it is regular (creating a sense of expectation), then it has a higher probability of creating individual behaviors over team behaviors unless your team remains constantly aligned to itself (resources typically fluctuate too much for this to be assumed).

If a reward is simply a show of appreciation and a call to what behaviors or achievements the team should continue to grow and repeat, then this has a higher probability of creating a collective and positive team behavior, especially if it is unexpected (not scheduled), and driven by the team.

Feel free to include your own thoughts in the comments, but I have to say that I'm not very open to debate on this one.

What is Iteration Zero?

2009-11-09T14:09:00.004-05:00

Someone asked a very interesting question in the Agile Alliance LinkedIn group. Discussions about iteration zero have come up before, but this one was specifically focused on the situation where the architecture was not well understood.

In case you are new to Agile or Scrum, iteration zero is the term for that first sprint where you know you won't be delivering software that is adding value for the customer. It's the "let's-get-our-ducks-in-a-row-so-we-don't-bomb-the-first-sprint" sprint.

Many people use sprint zero when they transition to agile for converting their project plan into a backlog and seting up the environments needed for CI and other XP practices. Some use it to kick off a project and understand the underlying system being built on top of.

In this discussion though, it got me to thinking about a past project where we were starting from scratch. We had nothing, and we had never developed in this technology before. So, what to do?

Remember, a sprint should always have an outcome or goal. And, it should always be demonstrable! The original poster asked about unknown architecture, common impediments, and differences to non-agile projects. Here's what I contributed to the forum:

Iteration 0 should result in a compiled installable "Hello World!" system (example: user shall be able to login and logout). Common impediments are purchase, license, hardware, network, and system related.

In an ad hoc PM practice (or traditional), there would be a huge "balloon payment" (to borrow from technical debt metaphors) at the end of the project to take this built system and install it in the real world. Iteration 0 is a way of beating this problem up front and then refactoring along the way as you learn instead of having to rebuild based on the mistakes uncovered at the end during "stabilization".

What do you think?

The "decline" of Agile is our own fault...

2009-11-05T15:18:00.012-05:00

I've been thinking about this for weeks. I'm still struggling to verbalize it. I could probably white-board it easily face to face; but I'm forcing myself to blog about it to see if anyone in the community reacts.

I'll start with the triggering thoughts first...

Martin Fowler gave me a new term at Agile East 2009 last week. The term is "Semantic Diffusion". He described this as the current trend of terminology diversity, dilution, and mis-use as agile has grown. He implied that it is the cost of growth and success of the movement.
I had a great conversation with J.B. Rainsberger while he was in Philly that same week. We discussed my thoughts and they intrigued him enough for me to continue pondering.
In the last year, I've had many a peer either complain about random factions in our community, or express a "loss of faith" in the movement at large. Frequently this is triggered by some new certification group or consulting firm charging high rates to "help" a group go agile with the wrong intentions.

I've come to the conclusion that Agile has NOT outlived its worth, its terms, or its time as seem people have started to imply (I refuse to allow Agile to be a dirty word)... instead, we are doing a bad job in the community at sustaining its applied success.

Now to the core of my point... I summarize it all right now!

By raising the issue of Semantic Diffusion, are we calling out an issue that needs to be guided more pro-actively? Or are we using this as an excuse to accept "the inevitable"? Are we doing anything to cause this problem to grow?

I'm going to state right now that I think we are. We need to stop looking outward for the cause and instead reflect inward.

When I started in the agile community, I worked with several great coaches. These were individuals who had proven experience in Scrum, XP, and other practices. They were "journeymen" with an interest in showing others how to do it. They insured that I learned how to do it correctly. I wasn't on the internet reading and learning about it, I had hands on coaching. Thus, I came up to speed quickly and I had a very positive, thorough, successful experience.

When I think of anyone entering our community, I hope they might learn through this same type of experience. Unfortunately, I believe the opposite is happening more often than not. Why?

Well, where are those agile innovators and early adopters now? Many of those folks have worked in agile for so long that it is easy for them to take these practices for granted. Their Ri level experiences have allowed them to forget the Shu level needs. They've moved on to much bigger problems like Enterprise, Off-Shore, and whole system optimization. These are good problems to solve, but you have to teach several coaches to replace you!

I also hypothesize that every new "generation" in the community learns at a quicker rate. There are more resources available, more lessons documented, more case studies published. If you take the right path, it is easier to get up to speed than in the early days. With this, people more quickly become successful (or not) and the gap between the Shu and Ri level groups becomes wider. When I entered the community, I could work with the Ha level group; but this group is a smaller percentage of the whole now.

When I went to the Agile 2007 conference in Washington D.C. (my first), I quickly learned that I was a Ha level user. As many people were asking me for insight into my experiences as I could find people to ask about theirs. It seemed that there were a small group of people that were innovating, and the rest were split evenly between learning and using. Now I feel as though (based on the community at large), the Shu level group greatly outnumbers the Ri level group due to market hype. The Ri level group is looking forward to innovate and there is not enough Ha level people to support the Shu group. I commonly find myself talking to a Shu level person asking about agile that doesn't know about the manifesto and haven't heard of the many important names or bodies of work in our community. Whoever planted Agile in this person's head didn't do a very good job in my mind.

And here is where the bottom feeders step in! Want to know about agile? Let me re-purpose my old pitches with these new buzzwords and charge you money to learn about something the wrong way. Everybody is talking about it, and you can't find anyone to help... so I'm the best you've got. Slap a few acronyms on your resume and hand you a certificate on the way out and you'll be dying to hand me $1500 to keep up with your peers.

So... if you've been doing agile for over 3 years and you've been successful at it, what are you doing to help the community? Are you bringing your experiences to folks and sharing them? Do you venture into communities where there are people at a different level than you? Do you explain what worked for you, or do you tell them how their approach is wrong? Do you throw the book at people and shake your head, or do you wrap your arm around them and bring them into the circle? Are you too focused on innovating to see who we are leaving behind? Do you focus on everything a person is doing wrong, or do you help them find something to do right? Do they see the benefits after they've tried it, or do they just follow this new set of procedures you've described?

Why does this matter? Because unless you are going to spend the rest of your career working with the same people, you may someday be working with one of these poor lost souls who has been taught everything wrong. You may take a job with a great agile company to only find out that the leadership has it all wrong and make your life one living hell. If you don't want to argue about what agile really means in five years, or have to invent a whole new set of words for the same things that we lost to "semantic diffusion"... then we have to start working on that now. I'm not talking about holding down our turf and fighting every idiot that says stupid things. I'm talking about leading by example, sharing information, proving success, and helping others. These are the same ideals that started the agile movement in the first place.

If everyone is learning faster and the gap between Shu and Ri is getting larger, then we can't expect the people behind us to train everyone that is entering the community. We have to still spend some small amount of time continuing to mentor the people catching up to us. Somewhere in that talent pool is the next Gordon Pask Award winner.

And this is why I started blogging; I wanted to pass along the knowledge that people have passed me. I have now spent a year learning by blogging and sharing by tweeting. I continue to share through Twitter and LinkedIn conversations, but I've been forced to cut back on the blogging due to the recent addition in my family. I'm asking all of you to consider these points and not forget that not long ago, you were also new to agile. People need guidance on how to start with agile, and we shouldn't allow them to be led astray by the snake charmers and other bottom feeders latching on to our community. It is in our best interest to reach back and pull people up with us as we continue to grow. That's my challenge to you!

Semantic Diffusion is a disease that should be fought during the normal lifecycle of a movement. It is a rallying cry for continued guidance and debate with the newest members of our community to insure the tribe moves in a common direction. Do not try to control the community and define it, just get involved enough to make sure you provide opportunities for people to learn from your experiences.

Note: just to be clear, I am not stating that certain people have left their posts. Everyone still hears the voices Fowler, Martin, Poppendieck, etc. I'm saying that as the numbers grow, many more voices need to be added to this core set.

Agile East 2009 by Thoughtworks

2009-11-03T17:14:00.006-05:00

I attended this conference Thursday October 29th in Philadelphia. There were two tracks on the agenda; I attended the business track and I brought a developer with me to attend the technical track. In summary, I was not invigorated at the end of the day like the Agile 2009 conference, but this is the cost of fewer sessions to pick from. The content was relevant, but not much was new for the folks like me who have been following agile for over 5 years. That being said, it was a networking opportunity with other agilists in the area. The following are the notes I took, there’s a few good nuggets in here-

Martin Fowler – The Essence of Agile

Very good job of explaining the “why consider agile” pitch without using the word waterfall or calling out PMI/PMBOK. This made it less combative than other things I’ve heard and was a note I hope I can carry with me during my own conversations.
Called out the concept of “semantic diffusion”… the current trend of terminology diversity, dilution, and mis-use as agile has grown. He said it is the cost of growth and success of the movement. I like this phrase and will use it moving forward.
Stated that Scrum = adaptive planning without forcing evolutionary design ... thus Scrum is not good enough by itself. Agile requires adaptive planning AND adaptive technology (evolutionary design) to succeed. I counted that as another vote for hybrid agile, be it Scrum/XP or other.

Martin Fowler – The Value of Software Design

Great overview of Technical Debt. I’ve never seen it to this level of detail and I found this to be the most valuable talk of the day. His mention of recent debates with Uncle Bob Martin on this topic was civil and talked of their similarities instead of their differences. His short impersonation of Uncle Bob was hilarious (“Thou shalt not name your variables improperly…”)

Discussed the concept of tradable quality

lower quality = faster = more features sooner
UI & defects - visible to user
good modular design - not visible to user

Proposed the “Design Stamina Hypothesis”

no design - over time, more effort to get more done
good design - over time, less effort to get more done
each start out the opposite of this, but cross and become true within weeks (much sooner than most assume)

Discussed accidental vs. essential complexity

Accidental - caused by sub-optimal design
Essential - chosen, prudent
Both are technical debt in his mind

Likened technical debt to a mortgage metaphor

the creation of technical debt is the principal
the interest is paid every time a new feature added
with every new feature you should decide to pay interest (build on top), or pay principal (go back and fix core)

Explained the cost/value of technical debt

interest payment cost = story estimate - story estimate if debt was fixed first
principal cost = estimate cost to fix principal/issue

Causes of Technical Debt

You don't know how to do good design = reckless, inadvertent debt
Ship now, fix later = prudent, deliberate debt

Debt is not right or wrong, it exists; the question is how do you deal with it?

Being reckless with your debt is like maxing out your credit cards

Martin Fowler – The Controversial Topic of Diversity in our Industry

There is a lack of diversity in profession (Women, African Americans)

They under represented compared to population… Why?

We have a problem, especially when you bring in badly treated history for these people

This is a power issue, what do we do about?

Don't shift imbalance of power in wrong direction with inappropriate actions
Humor only works for lower power people towards greater power people

It is important for our profession that we care about the professionals in our space (both peers and customers)

Software development is a leading role in the world!
If we block access to these minority, then we lose access to potential talent

Carl Ververs – Change Leadership

If you have followed Linda Rising, Esther Derby, Diana Larsen, Dale Emery, or some of Alistair Cockburn’s work on teams, people, trust, communication, psychology, etc… then this session was a repeat of pieces of their work I’ve seen in Agile 2007 and Agile 2008 or their books or blogs.

That being said, many people in attendance that day were new to agile, and this was a great session for them!

Joseph Zenevith – Agile Estimation Patterns and Pitfalls

If you have heard about agile estimation (as a process), but are new to agile and trying to implement it… this was a good session to help you get started and avoid the pitfalls. Discussions around sprint zero, sizing, etc.

Ross Pettit – The Financial Implications of Agile

This session was over my head (and most of the other attendees based on the body language). Thank goodness they did this over lunch. That being said, it was perfect for a CFO or anyone focused on how projects affect the profit margin of the company. I took a few notes-

Capitalization - Agile projects have a higher % of potential capitalization than traditional PM

capitalization = good = helps profitability
Forrester claims that agile projects are 40% cheaper

Cash Flow – agile projects don’t mortgage the future by deferring integration, testing, NFR’s

Less “balloon payment” surprises at the end of the project
Story/Backlog Item = $ turned into a result (not $ turned into a % effort complete)

Yield - a story is a focus on maximizing yield vs. containing cost (invest in the right stuff)

Volatility – investors hate since agile since it isn’t predictive/deterministic

old belief system is false though, so it is about education
agile projects will fail faster, this is a risk mitigation

New Exposures – failed projects and lost people can’t be capitalized

can cause a liquidity problem
solvency is a problem if people are lost (lost investment)
mitigate by aligning finance planning to iteration delivery and diversify investments

Greg Reiser – Redefining App. Dev. w/ Offshore Agile

Because I have experience in this area, I didn’t take any notes. My personal experiences were on par with their discussion. The main message- Make sure you are conscious about going down this path. It will not save the amount of money you believe up front, it can provide access to talent you don’t have, and it can be done (but not easily).

One thought that popped into my head as they were talking: How do you minimize / mitigate causes of technical debt in the offshoring model? Do you review the all code? Woah… someone should tackle that problem!

Tiffany Lentz & Manu Tandon - Applying Agile in a Non-Technical Area of the Org

This was one of the main reasons I wanted to go to this conference. Unfortunately it was a disappointment. It was a case study (I never find these as helpful as other sessions) and I missed that it said “applying” in the title instead of “convincing”. I need ways of pitching Agile to non-tech people. The session was about Scrum and a PMO setup for two teams that included non-software people (but many of the same roles you’d find on a scrum team).

One quote I liked: think of work completed as consumables downstream, not deliverables! (Interpretation- make sure people are supporting something, not just checking work off!)

The PMO had an interesting approach; instead of mandating process, they mandated required practices with multiple ways of achieving them. Examples included: estimation by the worker (not manager), work must have acceptance/done criteria, prioritization by the customer (not mgr). Because of this approach, “business value delivered” became an important discussion point within teams, unprompted and on its own.

Best Of- you've listened to me ramble for over a year!

2009-10-05T16:06:00.008-04:00

For those of you who follow this blog, I apologize for my recent calm. I've tried very hard to provide you value, and you've rewarded me with wonderful support, great conversations, and plenty of good feedback. But... in case you haven't heard, I do have a good reason. Before her arrival, I knew this might happen and tried to combat it with my pre-written Quote Series... but I underestimated how long it might take to regain normal life flow (this topic was raised in my last personal retrospective).

I've had the energy and sleep to continue absorbing from the community; but the only thing I've been able to contribute back is my agile focused Twitter stream. It has been over a year since I started blogging and I'm pleasantly surprised by the traffic and global coverage of my visitors. Until I can get back into the rhythm of things (hopefully in the next month), I wanted to leave this "Best of Agile Commentary" list in case you joined me on this journey mid-stream.

Top 10 blog posts in the last year based on your clicks (in reverse order)!

Participate in change, don't expect it to happen Agile is not just about managers changing
Cadence... I used a metaphor of cadence from the military to understand stand ups and feedback loops in agile
What is Shu Ha Ri? An overview of Shu Ha Ri… a very important learning principle
What is sprint planning about? Focus on the core intent behind sprint planning
Shorten your iteration... One of my first posts… shortening your iteration avoids mini-waterfall
Walking the board... We were one of the early adopters of the "walking the board" approach where we don't follow the "3 questions" in our stand up
Create a proper estimate scale... Popular how-to on creating a story point estimation scale
UX and Agile, how do they mix? Riding on my past usability experience, one of my first posts about User Experience within Agile
Snake on the wall! A great way to easily put your finger on waste and distraction with the team… every time this post gets quiet, it suddenly fires up with traffic again after a few weeks from a new source!
Post agile, one third of you will be gone... Most popular blog post ever about my first agile transition. It created controversy, was picked up by Kent Beck and flagged high on Reddit. Some even went so far as to say I sounded like a cult-member! You either get it, or you don't. When it happened to me, I was a convert, I'm now a pragmatist.

And here are three of my favorite notables that didn't make the traffic-based cut:

Puppy vs. Pitbull... One of my first posts about team dynamics and personalities
Before agile came along, life was easier for me... Reverse psychology at its best about the good old days
Bored in the standup? Raise your hand! How we combat tangents during our stand up

Thank you for your continued reading, challenges, and criticism!

It's all about getting groceries...

2009-09-24T08:34:00.004-04:00

When the average college student goes to college, they suddenly have to fend for food themselves. Most campuses provide some type of food source insuring students don't starve to death, but cafeteria food isn't always up to snuff for the tastes of the average 18 year old so they wander out and make their first true grocery run. How does this typically develop?

Phase One- Wander around and find stuff that seems like a good idea.
Result- Realize very quickly within a few days that you forgot stuff that you needed and what you got wasn't really a wise choice. That 3 tub pack of chocolate Kozy Shack pudding seemed like a good deal until you went home and ate it all within 24 hrs. Now you need to make another trip for food that will actually give you some energy for mid-terms.

Phase Two- Realize over time that you don't like wasting time grocery shopping; make a list of groceries and go get those items.
Result- This helps add efficiency, stay within a budget, insure completeness, and aids in blocking useless (or unhealthy) purchases.

Phase Three- You quickly get bored of canned food, cheese n' mac, and spaghetti; it's time to decide what you want to eat/cook in the coming week, then make the grocery list
Result- You shift from always having stuff in your kitchen, to having what you need to make the right meals from that stuff. By working backwards, you insure you are happy with the outcome.

So, what does this have to do with agile or project management?

Phase One - I can't tell you how many companies have a development team that just wanders around and does what seems will help run the business or quiet the screaming managers. Kind of like the hungry college student's stomach, this is simply an id response to filling the basic needs. Unfortunately like the cozy shack pudding example, this doesn't always turn out best for them either.

Phase Two - There comes a point of time where the team can't keep everyone happy. Work starts falling on the floor and some things don't get done. Organization is suddenly required. The team has to start making lists and prioritizing work. They have to consciously decide which things won't get completed to insure that the right things do get completed. They need to stay focused on the list and not everything else that draws their attention (backlog management anyone?)

Phase Three- To really mature as a team, you have to start focusing on your DONE criteria. What is being accomplished? What is the goal you are trying to reach? What is the business value being achieved? The work isn't DONE until you meet this!

Now, lets assume that college student is growing up... or maybe they are maturing their cooking to impress someone they are dating:

Phase Four- ask the people who ate the food what they liked and didn't like. Adjust selected meals accordingly and then adjust the grocery list.

For the agile team... this is the retrospective.