All That Jazz

On the last day of the Monospace conference, one of the open space sessions was Miguel de Icaza from Novell discussing his jazz band management style. It was an interesting look into the way the Mono project team works and learn more of the personal history

The Mono team had several members at the conference and watching them interact and hearing about the work, it sounds like a great environment to work in. I've been thinking about Miguel's talk since then and what lessons could be taken to help other teams be as tight knit and effective as his team.

First, why were we discussing jazz? Miguel compares his team to a really good jazz band. They are really sharp and can take the lead in an area that interests them, just as different members of a good jazz band can take the lead in a song and everyone else can support and play off their lead. Sure, there are times he sets a direction or throws out a big goal, but then the folks on the team can run with it, bring in things that interest them or help support the people taking the lead.

What troubles me though, is how unique is their situation? The people on the Mono team are really sharp and super passionate about Mono. It is rare to find teams that are so good at what they do and so committed to their cause. No wonder they excel and Miguel can have such a loose style and they have such fun together. Sure it would be great if we could all pick a team of all-stars to work with and have everyone jamming to the same tune, but how many times have you been in that situation?

One lesson that I think is generally applicable is the way they recruit for the Mono. Since they work with Open Source, they get to see people contribute, interact with them in a distributed environment, see their passion for the project and get to know them before they ever bring them on board their team.

Great for Open Source related projects, but how does this apply to non-open source projects? How can you see how well people fit and what their knowledge and skills really are? One day of interviewing usually isn't enough especially since we are often "testing" skills like "writing pseudo code on a white board" that aren't really part of what we expect people to do in their daily work. Plus, we don't gauge how well they interact with the team day to day, so we don't have a sense how they'd fit into the team game that is building great software. Most companies have a 3 or 6 month probationary period for new hires when they can be let go for whatever reason, but this seems to only be used in cases of gross incompetence. Psychologically, the team and hiring manager already committed to hiring this person, so they don't want to admit to a mistake and let them go.

A good alternative would be to hire the candidate as a contractor for a short specified period of time. For agile teams that have defined iterations, a couple of iterations or sprints would be enough. The team would have enough time to get to know the candidate, the candidate could show off their skills in a real environment and everyone would know up front the length of time and that this is an experiment.

What do you think are the best ways to add a new player to your band?

PS- Gary Sherman had a great post summarizing the Mono conference and Innotech.

A Different Route to the App Store

Good stuff at the first day of MonoSpace. A definite highlight was the two sessions on MonoTouch. In case you're wondering, Mono is a framework that allows you to develop .Net applications for more than Windows- you can target Linux, OSX, Android, and Amazon's EC2, among others. And, using MonoTouch, you can build .Net applications for the iPhone. So, you can leverage your C# (or, at least some instances using F#) knowledge and skills, rather than learning Objective-C. Of course, there is still a learning curve- you're designing an iPhone app not recreating a Windows form on a different platform so there are different usage patterns and there are extra steps in wiring everything together, as you'd expect. Still, seems well worth using it for .Net shops looking to reuse code and leverage existing skills. Plus, it is actively being developed and keeps getting better- they announced today the release of a debugger to run on the iPhone.

The team that developed MonoTouch had several members present - they are justifiably proud of their achievements and looking for feedback, bugs and real test cases so they can tackle new improvements.

Taking Innovation Games for a SPIN

I'm a big fan of Luke Hohmann's Innovation Games. They are a fun way to gather qualitative information about your products from your customers. At last month's Austin SPIN (Software Process Improvement Network) meeting, I had the privilege to help facilitate some Innovation Games. Jeff Brantley did the heavy lifting and presented an overview of the games included in Luke's book. Then, we divided up the group and played a couple of games.

My group played Speedboat to get some ideas around what things were slowing down people's process improvement efforts. I chose this topic since it had been mentioned at last month's meeting that the officers were soliciting ideas for topics at future SPIN meetings. Instead of waiting for folks to email items in, playing Speedboat gave us a chance to quickly get ideas and conversation from a dozen people all at the same time. As we looked at similarities between items, two areas that stood out to me were "people issues"- getting and keeping commitment from people at different levels in the company and cumbersome change processes (ie- Change Control Boards (CCBs)). Plus, everyone got some experience with a game.

I've been impressed with the Austin SPIN meetings I've been to recently. The group is energetic and engaged and the officers seem very focused on bringing in topics and presenters that have something to give. I've learned new things at each one and this professional development focus differs from the SPIN meetings I'd been to previously. Admittedly, those meeting were over 10 years ago, but they seemed to feature a speaker trying to sell a tool and a bunch of people looking for jobs. Neither is a bad thing, in and of itself, but the mismatch between presenter and audience made for a depressing evening. Not so anymore!

Another thing that this meeting reinforced was the flexibility of the games. Besides being great for getting qualitative market research, I've used them for retrospectives, community learning around Agile requirements, and process improvements. Jeff mentioned using them with churches and community groups for planning. And now for generating program ideas. Leave me a note with any other uses you've found for Innovation Games.

Now, get out and play!

Looking Back to Move Forward

Retrospectives are certainly a central part to the way most people adopt Agile. Similar to previous incarnations, like Lessons Learned and Postmortem sessions, one improvement is they are held frequently and not just at the end of a project or, even worse, just when something has really gone wrong. I'm a fan of them and of having them with different scope- not just focused on the last iteration, if you're doing time boxed iterations. I presented an experience report at Agile 2008 on holding release level retrospectives.

Tonight, I get to participate in a panel discussion of Borland's time in Austin at Agile Austin. It is a retrospective about a period in the company's history when we were doing a lot of work to adopt agile and what lessons we can learn from that.

Come by if you get a chance!

More Agile Certification Talk

I wrote some on this topic, but it is still very popular on the various lists. A blog post I liked was Derick's on the Los Techies Blog. I thought he was very thoughtful and like his comparison with the Master's and PhD thesis defense. That is one thing I was curious about when I submitted my Certified Scrum Practitioner application- would there be follow up and some justification or defense of my answers? Or, would it be rubber stamped? I'm not sure how extensive the review process actually was, but I do know I was never contacted for follow up, just notified of approval.

So, should I feel bad about having my CSP? And mentioning it on my resume? According to Scott Ambler, I should. In his mind, I am ethically liable for the sins committed under the umbrella of a certification program that I don't completely agree with (as I stated in the earlier post). Note- Scott is not against certifications, as this Dr. Dobbs article makes clear, he just has severe issues with certifying "Master's" after a couple of days. While I noted the same concern, I haven't taken the moral position he has. The requirements for each level of certification are publicly available - the Scrum Alliance wasn't perpetrating a hoax on the public or potential employers. HR departments or hiring managers that require a particular certification without understanding the rigor of the certification process are the ones liable for the candidates they hire. Just like I wouldn't blame Microsoft if someone hired an MCAD without validating that they could actually develop applications and hadn't just memorized test answers. Maybe I can gain absolution since I cite the more stringent CSP designation and not just CSM? In Scott's eyes, I doubt it since I'm guessing the self-reported actions on the application are not validated by anyone for quality or effectiveness.

Writing this post, I had multiple tabs open in Firefox that I'd opened over the last couple of days as I saw links in Twitter on the topic. I frequently do this until I have time to go back and actually read the posts. The last tab on this subject was Uncle Bob's reply to Scott's post. I didn't read it yet since I wanted to write out my own thoughts in this post before reading his. I'm happy to see him cite some of the same points I did- the process is transparent and understanding it is the hiring companies responsibility. It is nice when you agree with someone you respect and think highly of!

Finally, here is the Google group where folks are discussing the Agile Developer certification.

What *IS* software anyway?

Goofy question? Not really. Have you ever thought about what software is? Is it just 1's and 0's? Is it just the field where you are paid to toil away in? Is it a product to bring your company wealth and fame? Is it tool there to help others do their jobs, whatever they may be? Understanding that can really have an impact on what we create, how we go about creating it and how usable it is after we deliver it.

One of the valuable resources I've found out on the vastness of the web is the Software Process and Measurement Cast. Despite the unfortunate acronym chosen (SPaMCast? Really? How many people are going to click on a link that says "SPaM"? How many email filters will even let it through?), it is my favorite software related podcasts. Thomas Cagley has really solid guests from across the spectrum, asks good questions and related blog essays on each topic. My favorite episode of all time is Episode 36, which is actually the 2nd part of an interview with Phil Armour. Phil's answer to the question, "Software is not a product. It is a medium, it is a place where we store knowledge."

He explains that there are five such knowledge storing media in the world. They are:

1. DNA - where species store their knowledge
   
2. Brains - a transient knowledge read/write store
   
3. Hardware - he gives an example of a ruler storing the knowledge of length or a WW II bazooka that has the knowledge of how to aim it built into the sighting mechanism.
4. Books - especially the movable typeset books
5. Software - where the knowledge is not just stored, but it is executable. For example, software doesn't teach me to do the computations needed to compute the standard deviation of a set of numbers- it does it.
   

He has a lot more discussion about this but just the concept really made a lot of things click for me. When we think about software being a way to encode (and later execute) knowledge, it makes complete sense why long drawn out projects are doomed to fail. Even IF we could completely capture the requirements correctly at the beginning of a project, what we delivered at the end would still miss the mark. Why? In the intervening time the user would have learned some new things. New knowledge that we didn't encode.

And why do we have such a hard time getting the requirements correct? Because, most of the time, we aren't the ones with the knowledge we're trying encode. And the people with the knowledge don't know how to encode it. It is as if the only way a book could be published is if only publishers knew how to write. You know bass fishing and want to share that knowledge? Fine. Call a publisher, describe what you do and see what they come up with. Maybe, if you're lucky, the publisher will come out to actually see you in action and not just go off your description...or let you read an early draft. Oh, and when the book does come out, you now have to fish exactly the way the book describes it and only that way.

We also, all too often, misunderstand "the way we do it now" with absolute knowledge and encode it with no eye towards allowing it to change in the future once we, or the user learn something more. That doesn't mean coding so that everything is an option. But coding in a test driven style so that we have the confidence to go back and change something later and know we didn't break everything else? Try shifting from Scrum with fixed iteration length to Kanban where you have no time constraint but want buckets for the different areas the work item flows through- can your tracking software handle that?

It also tied in to some of the Real Options thinking. Why do options have value? They are giving you some freedom before you've encoded something, which is then costly to change. Time to get more of the knowledge.

Phil also has a good point about things really taking off when the medium is applied to itself. Like when steam was used to power manufacturing lines to make steam engines. How well do we encode (and execute) the knowledge of how to build good quality software into the building of software? Automated testing and continuous integration tools are a good start, but where else can we apply it?

Thoughts on Certifying Scrum Developers

Responding to Ron Jefferies request (via Twitter) for thoughts on a Scrum Alliance Certified Developer, I put together these ideas. I'm sure many of these thoughts have already been covered in Alliance conversations and the exhausting threads covering this on various lists, but it helps me organize my thoughts. First, allow me to start with a bit of my background, in case that helps set the context I'm coming from, with regards to certifications. I was a charter member of Microsoft's Certified Application Developer (.Net) certification, a Certified Scrum Master and a Certified Scrum Practitioner.

The interested parties in certifications are the people wanting to be certified, the people hiring them and the Alliance as the certifying authority. Are the interests of all three equally weighted? I thought of another interested group the training/testing delivery people.

Looking at my experiences for why I pursued certifications, one primary reason, especially for my MCAD and CSP ones, was to differentiate myself in the eyes of potential future employers. A secondary interest for the MCAD cert and a primary one for CSM was to learn more in those areas. Differentiation and education are pretty common for others I know that have pursued certification, usually pretty heavily weighted to the former. As such the pursuer of certification wants the certification to be difficult enough to provide real differentiation but still achievable in a reasonable amount of time and at a reasonable cost.

Looking at what I have liked and disliked about each, I feel that the CSM certification is too easy to obtain, an opinion I expressed to Mike Cohn after he delivered my course. Some of that is an unfortunate side effect of the title Certified Scrum Master. I'm being certified as a Master of something after a couple of days of training? Really? And then that is the most recognizable title in the field? I wish the toothpaste could be put back in and the initial certification was as a Practitioner (or Apprentice), the later one as Master. I liked the extensive application process for CSP. That felt more substantive. Unfortunately, I have not discerned much talk int he community of the importance of being a CSP or any difference in interest from potential employers. This is a current interest since Borland was acquired by Micro Focus a month ago. :) For the MCAD, I liked the Core + Elective set up so that you could focus on areas of interest or relevance. I did not like that it was a developer certification based on multiple choice tests.

Turning a bit to the hiring company side, I wrote here about some things I look for when interviewing candidates and I've been thinking about this conversation on the Software Craftmanship list about selecting for the wrong things in the interview process and this post on weeding out gross incompetence. I'd like to see the certification be tiered, just not with 'Master' at the first tier. When meeting someone with the first tier of certification, I'd know that they had a base level of understanding of the Scrum methods having been in a course for a couple of days. When meeting someone with the higher tier, I'd know that they had been on Scrum projects for some amount of time and had to go through an application and review process to be approved. An unanswered question in my mind is related to the Craftmanship discussion - how do I know they were effective as part of a team delivering software? It is probably too subjective to be answered in the certification process. The quality control aspects of both the course (material and delivery) and the approval/review process being under the purview of the Scrum Alliance are also important to the certification retaining value for the certified developer and the companies.

Going from the starting point Ron specified- that there will be a Scrum Certified Developer what would like to see it entail?

Staffing Agile Teams - What to Look for in a Team Member

Another of my posts from Borland's Agile Transformation blog. I know a lot of people looking for jobs right now and I'm hoping that this helps shed some light on the perspective of what the people on the other side of the interview are looking for in an Agile environment. Or, at least what I look for:

I read an interesting post about Scrum related job opportunities increasing and the author (Robin Pillay) posed three good questions to his readers:

1. Where do you see Scrum in 5 years time in organisations?
2. Every day I come across many candidates with no Scrum background that very keen to work for organisations that use scrum. The issues that I’m facing is many organisations always seem to want candidates from a Scrum background what would you recommend to candidates with no previous Scrum experience?
3. What changes have you seen working in organisations that use Scrum compared to organizations that don’t ?"

I want to look at question #2, since I think there is a parallel question: If I'm staffing a Scrum (or Agile) team, what do I look for in candidates who don't necessarily have Scrum experience?

In my role as a ScrumMaster I've been involved in the interviewing process for many Scrum team members. Often these folks don't have prior history with Scrum, so I first give them a quick overview (this picture is really useful). A candidate without experience in Scrum should at least know how it works. Mountain Goat and others have lots of good (and free!) introductory material. For me, it's important to see that they've done that homework. Having some questions for the Scrum team on how well different Scrum practices work would be a plus for a candidate.
After the overview, I like to see is how the candidate contrasts this description of Scrum with the way they currently work. Do they seem leery of the change? Are they reluctant to work in such a highly visible and accountable way? Do they see benefits to Scrum from their current job? Are they eager for the high amount of interaction with their team? Will they pitch in to accomplish the goal or want to stay in a specialty?

It is also important to have lots of time in sessions with other team members. Not only are the other members in the best position to assess if the candidate is technically excellent, but they also have a great read on how the person will fit in with the team. Good teams are very vested in the hiring process since they know they'll be relying on this person to help them achieve the team goals. The best advice I can give to the candidate going through this process is the tried and true "honesty is the best policy". Don't try to bluff your way through since you'll be working really closely with these folks if you are brought onto the team. Sometimes flexibility and eagerness are more important anyway.

Finally, some thoughts for those candidates who do have Scrum experience. I'd expect to hear questions from them about adaptations the team has made to "by the book" Scrum, and for the candidate to be able to describe modifications their current team made over time. This shows the interest in learning from retrospectives and a dedication to continuous improvement.
I'd be interested in hearing from others. How do you assess candidates that aren't experienced with your methods?

Originally posted by Michael Maham on February 05, 2009 at 12:30 PM at http://borland.typepad.com/agile_transformation/2009/02/staffing-agile-teams.html

Update: There is a good conversation related to this on the Software Craftmanship group.

Update II: I like Richard Banks' approach to understanding technical competence

Do you design your work?

Happily, I was finally able to attend the Lean Software Austin group's meeting this past Monday. Scott Bellware was leading the discussion on Kanban and applying it to software development. Unlike some groups where the meeting is like a lecture, this was very participatory with lots of dialog from different folks. Maybe this is because the group is still comparatively small, or since the area is still new so everyone is willing to share and try to learn from each other...no one is worried about feeling like they don't do it "right" (yet).

One of the facets of Kanban that caused interesting discussion was the idea that work units should be the same size as they pass through the work flow. This is the ideal since it promotes smoother flow and is necessary in order for the Work In Progress (WIP) limits to be effective. Can it always happen? Of course not, but could it happen more often if we tried. I believe it was Scott who said, "Design the work and design the implementation".

After the initial revulsion to Big Design Up Front (BDUF), we've come to the understanding that you don't ditch design (of the implementation) altogether but you design appropriately. That the further away something is from being implemented, the lower the fidelity of the design. In a similar way, in the Scrum world, there's also the understanding that estimates of size get more accurate for a user story as you get closer to implementation. And there is some other "design of the work", but I think a lot of it is accidental and could be improved if it was done explicitly. For example, after sitting through a few interminably long poker planning meetings, Scrum teams, or part of the team-usually the more senior members, start to sit down with the Product Owner before the planning session to "groom" or "prep" the top part of the backlog. These sessions take a look at those stories that will likely be included in the next sprint and make sure there is at least enough detail or understanding for the team to be able to have the conversation during planning. Often, the result of these sessions is the Product Owner needs to further refine his thoughts or gather more information before planning.

One benefit to being more intentional about designing our work would be gaining more learning about how we did in retrospect. Teams spend so much time in planning doing story point estimation, but rarely have I seen them spend much effort at the end of an iteration looking at how they did on those estimates so they can be more consistent and more accurate in the future. In a Lean environment, inaccuracies in sizing the work would be apparent sooner since work that is larger than the standard will slow down the flow- starving the downstream parts and backing up the upstream ones. Just like designing the implementation, we want to achieve a balance to have "good enough" design of the work. For estimates of size, that might mean t-shirt sizes (Small, Medium, Large) for work that is some ways off and more detailed estimates as the work comes closer to being taken on.

Another benefit to designing the work, beyond the area of sizing, is it gives us a chance to recognize gaps in our skill set by looking ahead, or special circumstances that might apply. The larger the gap, the earlier we should look out how we're going to fill it, maybe by bringing in a specialist on a contract basis so we can learn from her, getting some training, doing early experiments or some other option. Special circumstances might be recognizing that a piece of work might be better done before someone on the team leaves for vacation. So, the work could be moved up in the order to take advantage of his special knowledge or skills.

How much time does your team spend designing your work? How does this compare with the effort in designing the implementation?

For those of you in Austin- hope you make it to the September Lean Software Austin meeting!

The What More Than The How

I read a really good blog post on Mike Cottmeyer's Leading Agile blog titled "Why the Re-think?". I originally found Mike's blog via a link on Twitter (if you're on Twitter, I'm michael_maham, if you're not on Twitter, you're missing a great stream of information)

It is on getting the important things right- not a methodology or process improvement for their own sakes (the HOWS) , but because you're trying get value delivered to your customer (the WHAT).

One quote really stood out to me: "Its the value behind the practices... the WHAT behind the HOW... that is really important. We believe this is the secret to sustainable agile adoption in the enterprise."

I think the last sentence understates the case. It's not just the the secret to sustainable agile adoption (or CMMi based improvement or any other process improvement), but is the secret to sustaining your business. Great businesses know that- even as they are trying to find the next WHAT or a better HOW they don't lose sight of continuing to deliver that value to the customers. If a new WHAT is too fanciful, it won't benefit customers and should be dropped. If a new HOW delays, rather than delivers, value to the customer, it is not right for them. Even if that HOW has a fancy label like "Agile" or "best practice".

Fortunately, for those of interested in the HOW, when we keep our eyes on the goal of delivering value, there are lots of improvements devoted teams can make that really are remarkable and don't become dogmatic headaches.

The Mature Agile Organization

Another post I had on Borland's Agile Transformations blog:

Here's a quick note about a recently published technical note from the SEI: CMMi or Agile: Why Not Embrace Both? There's talk about it from some of the authors: David Anderson, Hillel Glazer and Jeff Dalton. I saw them and Mike Konrad discuss the draft at an impromptu session at last year's SEPG Conference and am heartened to see the progress being made in the communities working together.

I'll have some more thoughts on the technical note itself, but a bigger question in your mind may be "CMMi and Agile? Those can't go together." I heard that comment from a colleague the other night at dinner. I disagreed and my answer was "A poorly implemented CMMi based process improvement- one that mistakes the model for a process description and that doesn't keep a firm eye on the goal of delivering business value- won't be very Agile. And, a poorly implemented Agile based improvement effort- one that doesn't recognize the amount of discipline required, for example, or doesn't address what's necessary to scale up to an enterprise level- won't look good from a CMMi view. But, I don't want either one of those things!"

Do you agree that there's value to an Agile organization in looking at the CMMi?

Originally posted by Michael Maham on December 16, 2008 at http://borland.typepad.com/agile_transformation/2008/12/the-mature-agile-organization.html

What's missing from the Agile manifesto?

Continuing the reposting of my posts from Borland's Agile Transformations blog:

Coincidental to my fellow blogger Dale's attendance and coverage of the Agile Development Practices conference, iTunes downloaded an interesting podcast into my StickyMinds conferences subscription. It was for a short Q&A with Brian Marick about his keynote address at the conference with the intriguing title "Seven Years Later: What the Agile Manifesto Left Out."

Questioning the Manifesto? Isn't this, like tugging on Superman's cape, one of the things you just don't do? Well, since Brian 's one of the original thirteen signatories, he's in a good position to offer
commentary on it. The full text of his keynote is found on his blog, but the thing I took from
the interview was a main weakness in the Manifesto is not describing the internal values necessary for Agile to be successful, as opposed to the external values to make the business and dev team interaction successful. In the text, he lists the internal values as Courage, Working Software, Ease, Being Reactive, Fast Feedback, Naivete', Visibility to the point of Exhibitionism, and Joy.

One line from the written text that jumps out at me is "There are always tradeoffs between the values". To me, that means not just between the items on the left and right on each line of the original Manifesto, but between the lines. While this is not missing from the Manifesto, more people need an appreciation for this and to think about when it makes sense to trade off one against another. And that it is ok to do this. Everything can't be priority #1 at all times.

Two things I think are missing from the Manifesto are a recognition that it should change over time and laying out the means for such change. It seems remarkable that a document putting "Responding to change" as one of the top four values for software development would not see value in acknowledging that it, too, might need to change along the line. Brian touches on this in the interview and sees it as remarkable enough that the thirteen signatories could come together and come to agreement once. The odds of getting this to happen more than once are just too low, in his opinion, to believe it could happen. Still, that disappoints me.

Interestingly, a difference between the interview and the written text is that in the interview he mentions Skill and Discipline, not just as values but as ones that are lacking (in the case of skill) and more necessary (in the case of discipline) to make Agile work. I think these are very good points and are often overlooked. Do some of the values, such as fast feedback, visibility and working software combined with courage (to be honest about them and not fudge them for appearance's sake),
require discipline? A different set, like working software + ease, might require strong skills?

I'd be interested in hearing Brian's take on the relationships between skill and discipline and his other values. I was slightly disappointed that there wasn't more discussion of these two in the text of his talk since I'd say those are two big gaps in the internal workings of teams.

I leave readers with a different set of questions:

* Are we doing enough to recognize what skills gaps there are in our teams?
* How are we addressing those rather than making the team relearn all of the ideas that really experienced folks know?
* Are we sending enough developers out to conferences or other events with peers?
* Are teams putting up information radiators to reflect to themselves how disciplined they are?
* What do you think is missing from the Manifesto?

Originally posted by Michael Maham on November 26, 2008 at 09:04 AM at http://borland.typepad.com/agile_transformation/2008/11/whats-missing-from-the-agile-manifesto.html

Intro #1: What School Are You?

I always like when there is some introductory material on a blog- it gives you a sense of where someone's coming from and can help you understand their perspective. I'll have a couple of these posts- I have one from my former company's blog and I'll copy it here. Not because it is so valuable it needs to be reprinted :), but I'm not sure how long Borland's "Agile Transformation" blog will remain up now that they've been bought by Micro Focus. And I think it does a pretty good job of presenting where I'm coming from on process issues. So, here is "What School Are You?" (originally published at: http://borland.typepad.com/agile_transformation/2008/10/what-school-are.html) :

"I kicked around several ideas for an introductory post, trying to balance giving some personal background with something of broader interest....Trying to balance answering "Who am I?" for you, without being vain enough for you to instead ask "Who does this guy think he is?" Asking the question in the title gives me a good balance.

One of the ideas that has really helped me on understanding "Agile Transformations", both in myself and in teams that I see and work with is the concept of "shuhari", which defines the stages of mastering Japanese martial arts. Shu is the level when you start and are loyal to the "school" you are learning from- you're following the practices by the book. Ha is when you are understanding more of the principles behind the practices so you can go beyond the practices you learned in your school- how to extend them to situations not originally envisioned or what to do when a practice used to work or what ideas from another school you'd like to mix in. I get these two, but Ri? Ri is defined as transcendence when all moves are natural. I'll let you know if I experience this transcendence! In my book, it's not too terribly important where you start since people around you will get to the point that they're pulling in ideas from other schools. Or they'll be dogmatically stuck to the starting school and you won't want to hang around them.

So, what "school" are you when it comes to development and how to improve? For me, I started out seeing many different approaches to doing things better- some measurement driven, some from a maturity model, some from a vendor. It wasn't until we started using Scrum inside Borland that I saw something that I really believed in - the other results I saw from the others were just too mixed. Sure, Scrum's results are mixed but the experiences I've seen are much more on the positive side of the ledger. So, would I say I'm of the Scrum school? Or even the Schwaber Scrum school since that is the first book I had? Or the Mike Cohn Scrum school since he was the trainer in my first ScrumMaster training?

Nope. None of the above. While appreciating Scrum, serving as a ScrumMaster and seeing the way it benefits teams, I was exploring other areas of the Agile world and finding other approaches that resonate more with me. I haven't done hardcore XP. I'd like to say I'm of the Real Options school, but I'm not sure I could pass the entrance exam. The area that resonates the most for me is Lean, whether described by the Poppendiecks, David Anderson or Corey Ladas and crew. My personal exploration and experience with these schools of thought will be one of the many areas I cover in this blog.

So I'm interested to know, what school are you? "

(Originally posted by Michael Maham on October 29, 2008 at 07:20 AM)