STOMPing around with the kids

I started a program today with a 5th Grade Elementary class that basically uses Lego Mindstorms kits to introduce kids to Engineering concepts, this is through the STOMP Network.  We had a 4 hour training class over the summer, and received some kits to build robots with, I took it home but my 3 year old was not as patient with the kit as I had hoped; yeah I know, not realistic.  Still it was fun to watch him see the robot go around, and follow it some where it went and did a course through the house.

First day with this group was basically build a durable structure, in this case a chair, that can be dropped with a stuffed animal in it, I had talked about the class with someone else involved who said it was good to come in with a good and bad example.  I made a good chair, that holds up when dropped from knee height, and a chair that would break when it hit the floor, as expected most kids were pointing to the one that would break because they were familiar with those Legos.  Still it didn't stop their design process when the kids were told to make their own chair, in teams of 2's and 3's.  Funny how many different designs there were, and how many of them wanted to make wheel chairs, whether it was because there were wheels in the kits or they wanted to see something move as well I have no idea.

This continues for the next 8-10 weeks and looks like it will be fun.  Next week the kids should finish their chairs, then we move onto something else, eventually making a robotics car that they can program.  I have to get used to the programming interface again, thankfully I have time for that.

Who needs the Customer? We do.

I was recently discussing an upcoming project with the VP of our group, part of the discussion went to process (as I am the process wonk in my group) and inevitably it drifted to Scrum and Agile methods as they are something I have been talking about over the past year.  We do have a good methodology that works well for the development and testing we need to do, its not Agile and potentially could be, but would take a lot of restructuring that upper management is not yet convinced we need since we still deliver very stable software.  The next project has a PRD that was coming out, and the teams were reviewing the document I asked who was going to play the part of the Customer Advocate?  Who were our domain experts for the product?

The answer - QA.

I was a little dumbfounded, while I will admit we know the product and have a good idea of what a Customer is going to do with our software, were we really in tune with the day to day usage of the product?  Were we too close to see some things?  Was Development equally as capable since they do some design, which even our lab manager questions and he is representative of the Customer, but the response is the Customer wants it that way.  Which makes no sense to some of us, especially the lab manager as he is as close to a Customer as we get, but the response is sometimes that if we needed improvements or changes like we have mentioned they would come through support.  To date few have.  Still I kept coming back to the real question - is QA really the Customer?  Do we really have a good grasp of the Customer's needs and wants and know how they will use the product day to day?

I was not so sure.

Individually the QA Team has an understanding of how the product works, and what it should do, one or two of us have a wide grasp of the product while the rest know our areas really well and have some pockets of knowledge in others.  Its a complex product, but would a Customer really use all its features or just those that help them resolve their problems?  What were the problems we were trying to solve?  Those problems were stated and we knew them, and knew the areas of the product that solved those problems, the new PRD was more on topic with not only stating the problems but gave more detailed User Scenarios than we've had before.  Did that close the knowledge gap?  Not really, because we have a good grasp of the high level issues and stated problems, we know the solutions for them and how to test them - but something still nagged at me and it was historical.

Last year we had some discussions on how to improve things, we split into teams that discussed how to improve our process and product more - one item showed up on multiple lists - more meetings and discussions with Customers.  We don't often know who our Customers are, and in the two years I have been asking I have yet to get anything that shows what platforms our Customers run software on, the only time I know is when I get an issue escalated from a Customer.  Since "more meetings with Customers" kept showing up, were we really meeting the Customer's stated needs, or were we meeting the needs as filtered through the Product Managers who talked to the Customers about their needs?  Sort of like playing Operator, need A gets said to Product Manager A who then tells Need A to Product Manager B who is also hearing Need B from Product Manager C and its all filtered up into a document that states Need C, an amalgamation of Need A and Need B.  But does that make it a real example of the Customer Need or is there still a disconnect?  I'm of the opinion that regardless of how much a Product Manager discusses needs with the Customer there is a gap in either experience, knowledge or use that is not quite bridged.

When the same question came up later with a different group of people and there were discussions about the PRD and what we need, some said it was a good document while I and others said its nice but we need Customers to look at it.  Regardless of how much we know about the product and its use we often can't bridge the How, this is why people use the mantra of "eat your own dog food", if you cannot get the product to work in your environment for its intended use then no one else will.  Customer Advocates are good, and this is what I am trying to bring in for Agile because I think it will improve our product, we can have Customer Advocates at all levels and test or develop with that in mind, but sometimes you need someone outside all of that who will use the product and give you honest feedback.

In otherwords, a Customer.

Those Three Little Words (or is it four?)

It's something that I used to dread, after all the hype and the information on this that is out there I feared one day I will come into work and hear the words "we're going Agile".  If you wish to dispute my counting, feel free.  It's my blog and I count "we're" as one word, so get over it.

While expecting this to come out at some point, my fear was recently fired up again when I got a notice about a company reorganization (I think we have one planned yearly), and in it were the words - "we're going to be using Agile processes".  Yup, we're going AGILE!  There was no date on it, or really any reason why, I have my suspicions but I will keep it to myself.  Last summer I gave a short presentation to my group, I do one a month and let others do it when they want or if they have something good, and in that I went over my experiences with Agile and Scrum.  Agile was done badly, Scrum was done well, though after a recent test conference I can see it being improved upon.

We discussed the upcoming change at our group meeting soon after the notice came and generated two important questions we thought would be good to answer before proceeding:

1. What is the problem we are trying to solve?
2. How will Agile processes solve the problem?

Without knowing the answers to those two going Agile means little, you need a plan and you need a purpose, there is no way adding a process over what exists is going to immediately solve every known and unknown problem.  To me there are two main reasons that companies consider going Agile:

1. They have no process and saying you are going Agile allows you to say you are just in a phase of "adaptation"
2. The process that is in place has so many exceptions that its not followed, this is the second path to "adaptation"

I am not saying everyone is in that state, but some companies that are, and want to make things look good consider Agile as a blanket they can pull over everything and hide what should probably have more light shined upon it.  Take care when the company goes Agile, more than likely its not for the right reasons, and won't be done in a way to take advantage of its strengths either.