Because what you have works so well...

I heard a very dismissive comment on Agile the other day...from someone who has projects that are under-delivering and are past their deadlines....really? We can't stop and look at alternatives? There's nothing beyond the PMBOK we can learn from? I'm all for being discerning, even critical, but dismissive?

Why Agile?

A friend of mine sent me email telling me he'd been working with some Agile projects and was looking at working with a new group. The new group's management was used to traditional project planning and he wanted to know "Basically my question is that I am looking for material that has testimonials on what kinds of project management obstacles some medium sized companies have faced and how they overcame them while using the Agile methodology. Any links or references would be great if you have them."


Here is my response:
A good place to ask your question would be the Agile Project Management group. There's lots of PMP types on there or people who work with traditional PMs that might have some good advice.

Good cases I've seen usually start with "what we're doing now doesn't work" (because if it did we wouldn't need to change). Some of the reasons why and why other approaches are better:

• Development is an exploratory endeavor. Traditional project plans work great if we're doing repetitive tasks that are pretty well understood. Software development doesn't usually fit this pattern and so it is hard to lay it all out ahead of time. When we're wrong on the schedule, due to tasks taking longer than estimated (and we inevitably are), people still want to drive to keep the date and the scope, which leads to short changing the tasks at the end of the development cycle such as testing and documentation.
• Recognition of value can occur sooner. If we're developing in a truly iterative and incremental manner, we can release software that does something (and these should be the most important ones) sooner. So, we can start to get some of the value now rather than waiting until the end of a really long development cycle. Just like in time value of money sense, getting the value now is ore valuable than getting down the road in the future- we accumulate more of it over time
• In a related sense, being able to get software out early makes it better software in the long run. Developing software is encoding knowledge (see a post on that here), but the people who know how to do the encoding are not the same as the people who have the knowledge, typically. Only when the people with knowledge get it in their hands can they say what isn't quite right about it or how it could be better. So, the sooner we can get that feedback the sooner we can get it in the right direction, with less invested in the "wrong" direction. It wasn't intentionally the "wrong" direction but there is just only so much you can get right trying to elicit or review requirements.
  

Anyway, the 1st step- recognizing what is broken in the existing state is what can make the strongest case for change.

What would be your answer for why groups should adopt agile methods? And what material would you point them to?

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.