1. You’ll learn to stop saying “should” and “just”: I worked with a company that had a problem with too many bugs.  When a doozy would pop-up the usual all-hands-on-deck emergency meeting happened.  The output was “we should do X to make Y not happen again”.  Everybody nodded and felt great about this new epiphany!  Shame nothing actually got done.  When you say “we should do X” you remove all sense of responsibility on you and everybody else.  It’s an action-less modal verb.  I “just” thought this point would be valuable.  Did you feel the power of this paragraph dissipate?  ”I just through this point…” means I have no confidence in what I “just” said.  Stop saying “should” and “just”.  PSL will help you figure out how.
2. You’ll become more self-aware: Self-awareness leads to improvement.  I had many of my patterns reflected back to me during the week and PSL gave me many tools to figure out how to recognize those patterns and more importantly how to work on fixing them.  Other people aren’t the problem, understand how you intake and process information and you’ll be much more self-aware.
3. You’ll learn how to spot problems: Well duh, it’s called PROBLEM SOLVING LEADERSHIP, what did you expect?  Seriously though, I get criticized for being too negative because I do not, nor will I ever, accept the status quo.  PSL taught me how to do this, diplomatically and brutally.  I usually prefer the brutal truth yet I realize the need for telling the kinder truth sometimes.  If you cannot challenge the status quo and treat every problem as it’s own unique set of circumstances, (which they are, but generally humans use that as an excuse to not dig deeper “oh, it was an anomaly…it won’t happen again”), you’ll struggle with developing a problem solving attitude in your organization and you’ll be doomed to mediocrity.
4. You’ll Have Fun!!! PSL was a blast!  Intense learning, strong relationships were formed with people I never met before and it was extremely fun!  I do have another problem though.  The title of this post says ’3 Reasons’, yet I have listed 4.  How can I solve this problem?  ;-)

PSL will sell out fast, go sign-up now!

Jack described their ‘work board and stickies’ how they used that to manage their work, how they added daily meetings and how they improved by getting the team and product owner in the same room.

From our conversation I could tell, and he verified, that he didn’t know anything about Kanban and heard that Kanban was more of an advanced practice. While it was a brief conversation, I echoed back that I felt he was on the right track. He was getting the benefits of a continuous improvement mentally without using the A-word.

How refreshing, I remember about 10 years ago working in a company where we were doing the same thing. I had never heard about Agile at the time. Through experimentation we found out what worked for us.

If your organization wants to get started with Agile and Jack’s story sounds familiar to you, you may be on the right track already. You may be better served to get specifically educated on what Agile practice your current process resembles. You can do that by going to local events and talking to people in the community.

The worst thing you can probably do is to consider transforming to Agile because it’ll probably set you back further and erase the great progress you’ve already made.

There was a tweet I saw today that sparked this post.  You know the ones, like: ‘learning comes from failure‘ or ‘without failure there is no learning‘.  It sure sounds poetic and intellectual, but useless nonetheless.  I feel ok to say that because I used to say stuff like that.  Maybe I just failed with that messaging and now I have learned.  I’d like to think I just have more experience now.

So for those of you preaching “for learning to happen thou shalt must hath doth fail first…” enough already.  Work is hard enough without having to be told you have to fail before figuring something out.  Experience is the key, try shit out, get feedback and rinse and repeat.  That’s all that’s really going to work.

So how does this Starbucks handle it? The person who prepares the coffee takes and starts the order and for the second person in line to increase throughput.  By the time that person pays the cashier, their order is ready and out they go.  Quick and efficient.

Seems like common sense doesn’t it?  I wonder if the manager gets upset that they are breaking process?

On the flip side, when I go to Tim Hortons, it’s usually the cashier that takes the order and fills it so the next customer has to wait until the order is done.  Sounds like single-piece flow to me.  Makes sense for limiting WIP, might not be the right balance for getting customers through faster.

Of course it could just be my heightened senses as a result of the double Grande Americano I just chugged.

That reminded me of a recent sprint planning session our team had.  Our product owner considered customer value and done as being able to clearly show separation of presentation and data layers in a new service we’re developing.  I considered customer value being showing the user of the new service a simple interpretation of the data being shown through the service.  Very different perspectives.

For me ‘done’ is when the customer gets something valuable.  For our PO, ‘done’ is when he can be satisfied with the design of the service.  The team, done is when all the yellow stickies are moved to ‘done’.

The point is, my tax example is simple and very specific.  Just before I wrote this post I told my wife I finished both returns, filed mine since I get a refund and will file her’s at the deadline since she has to pay this year (booooooo!….for her!).  Before that, I have no idea what she thought ‘done’ was.

Software is much more complex than that.  One way of handling this is to periodically align the team during the sprint.  Oddly enough I did that yesterday.  Our standup felt kinda ‘status-y’ and there really wasn’t much talk about the actual work.  I pushed the team and asked them to say what they thought we agreed to delivering.  I asked the PO the same thing.

I was pleased to hear it was the same as what I thought so I wrote it down and stuck it on our release wall.  Might be tough to see in the picture, the green card on the left shows the sprint number and what our definition of ‘done’ is from the customer’s perspective since that’s what our sales and marketing team would find valuable.  They could care less if the service is de-coupled.

When you talk about ‘done’, be specific.  Scrum talks about delivering ‘business value’ and ‘potentially shippable’ software which is just a guideline.  Be specific and you’ll avoid a whole whack of ugle “hey, that’s not what I thought we were gunna get!” conversations later.

Keeping in mind that the average business person doesn’t really understand or necessarily care about technical debt, all they really wonder is why it takes so long to get stuff done.  Take, for example, the Rally story from Implementing Lean Software Development.   Rally started building their agile project management software and after the first year they accumulated ‘technical debt’.  Long story short, it took 14 months to get rid of it.  Read the book for the details.  Actually, read the book anyway, it’ll change your life.  So what can you do?  Read on…

Here’s a strategy you can employ to provide value to the business and pay down your technical debt at the same time.

Priorities, Priorities and More Priorities

Start off by figuring out what’s the next big thing for your business.    Drive company goals with yearly initiatives broken down into quarterly initiatives and use this as a guiding light to figure out what is important to the business.  When attacking technical debt you are more likely to get support from management if paying back the debt is wrapped in a business goal otherwise teams can just spin and spin on re-writes or re-architecture or other stuff that generally isn’t a good idea if it’s just done for the sake of being done.

Look at the Guts

Once you have the priority defined, use a project discovery session to look under the hood.  This should happen BEFORE estimates and commitments or release planning.  This is where tools can be very useful.  Tools like Sonar can get you great information about the state of the codebase that will be affected by this change.

Sonar will give you code complexity numbers, test coverage, duplication and a whole bunch of useful (and some not-so-useful) information that teams can use to help the business understand the effort required to make this business goal a reality.  You can also use the more subjective report that the team likes to call “man, this code sucks and is reeeeeally hard to change…and test….and…”

Decisions, Decisions, Decisions

At this point you should have a good idea of what the effort is to accomplish this business goal and now the decision has to be made:

• should you do the project at all?
• should you fix the boat?
• should you build a new one?
• should you just keep doing the same thing hoping it’ll be different this time?

The point is, you now have some REAL data in order to make a decision and it’s based understanding what the effort is to accomplish a business goal while considering the state of reality.   Teams generally have a good gut feel about this already but can be talked into into ‘just getting it done‘ or be too afraid to push back.  Having this data is a great backup to that gut feel.

Changing code for the sake of changing code to be better doesn’t make any sense.  If you have legacy code that works but rarely changes maybe there’s no need to eliminate that debt.    The best thing you can do is use business goals to drive technical initiatives because that is what will get management on board to influence a better way to work.

Now that you have some ideas for a strategy for paying off technical debt, I’d recommend Mark Levison’s article on what technical debt is and solutions for getting rid of it.

My preference is that the team delivers it as a whole with one team member taking the lead from iteration to iteration.  Who delivers your demo at the end of the iteration?  If you don’t like the options, feel free to comment!

[poll id="2"]

Experiment. Fail.  Learn, move on and get better next time around. That is what “being Agile” is all about.

There is no magic formula or checklist to make an Agile adoption successful.   It’s up to how willing the individuals are to accept help from a coach or how open they are to getting out of their comfort zone to improve on something that isn’t working.  Class after class I get bombarded with questions that range from how QA integrates with an Agile team to “how does Agile tell you to deal with the expense of buying a developer a laptop?”. (yes, that was a REAL question I was asked once).

Esther Derby posted a few months ago about 5 reasons to hire an Agile Coach which leads me to ask what actually makes a coach successful?  What makes a coach worthy of self-labeling himself a coach in the first place?  These are the top 3 attributes I consider to be the most important:

1) Self-less:  A coach must care about the team (and organization) and morally and ethically do what is right.   A good coach must possess the desire to work their way out of a job for the greater good of the organization that has invested time, money and most importantly trust in the coach’s abilities.  Now in the real world I am quite sure there are some folks who want to extend the gig as long as possible for security or other selfish reasons, but IMO that’s not the point.  If you are trying to teach and organization how to build trust, that lesson starts with the coach.

2) Honesty:  A good coach must be clear that the road may (and mostly likely will) get rough and there is a chance adopting Agile just will not work if the organization doesn’t want to change.    You can say “honesty is the best policy”  is a rally-cry or fluffy sounding but it rings true.  If you set the expectation that you will be honest regardless of how painful that honesty may be sometimes, a coach will stand to earn the respect and trust of the organization which is a first step towards having that spread throughout the rest of the organization.

3) Guide, Not Dictate:  Ok, so this isn’t so much an attribute phrased like the other two, but it’s important nonetheless.  As I mentioned at the start of the post, lotsa folks want the “how” without wanting to think about it first.  It’s important a coach help the organization/team/person get to the right answer for their situation.   An organization needs to learn how to becoming a learning organization and the best way to accomplish that, IMO, is to use the tools, knowledge and frameworks to help people find the answer that works.   If teams or individuals are making real attempts and showing true desire to adopt Agile practices, give them the freedom to apply what you have taught them.  Let them experiment and maybe they’ll fail, but if they have the desire and motivation, they will learn and improve.

I’ve always bought into the thought that skill and knowledge is never a problem.  Skills can be taught and knowledge can be obtained.  Motivation and desire are the most important attributes that help organizations or individuals commit to constant improvement.

Agree?  Disagree?  What other attributes do you think make a coach successful?

I would defintely prefer to see some type of scenario based exam so students can prove they can apply the knowledge gained in the course instead of a multiple choice exam.   It’s pretty simple to memorize a few facts and pass and exam however that is better than being given a certification based on the instructors assertion you deserve it.  Having said that, I’ve worked with some MCSE’s who passed the Microsoft exams but didn’t understand basic file sharing principles in Windows NT4.

This is a step in the right direction in making the certification more meaningful and difficult to obtain and it’ll be interesting to see what type of exam the Scrum Alliance can come up with.

Baptism by fire and blogs filled with wrong information wasn’t going anyway quick so I figured it was time for some training.  After I finished my CSM, it was pretty clear that Scrum is easy, but implementing Scrum is really hard.

There are some great articles out there about Agile but Travis Birch from Berteig Consulting posted an excellent article on what it means to be Agile. Some people think the ‘art of possible’ and other Scrum mantra can sound a bit hokey at times, but it really is a big shift in mindset to use Agile/Scrum effectively and Travis’ post is one of the best written posts I’ve read that summarizes what Agile is.